* [Qemu-devel] (Another) 1.4.1 -> 1.5.0 migration failure @ 2013-05-21 11:33 Nicholas Thomas 2013-05-21 11:55 ` Andreas Färber 2013-05-21 16:55 ` mdroth 0 siblings, 2 replies; 9+ messages in thread From: Nicholas Thomas @ 2013-05-21 11:33 UTC (permalink / raw) To: qemu-devel Hi all, Migrating from: /opt/qemu-1.4.1/bin/qemu-system-x86_64 -M pc -watchdog i6300esb -watchdog-action reset [...] to: /opt/qemu-1.5.0/bin/qemu-system-x86_64 -M pc-i440fx-1.4 -watchdog i6300esb -watchdog-action reset [...] I get: qemu: warning: error while loading state for instance 0x0 of device '0000:00:06.0/i6300esb_wdt' load of migration failed Perhaps a similar issue to the network device one? I'm afraid I'm not sure how to debug these... /Nick ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Qemu-devel] (Another) 1.4.1 -> 1.5.0 migration failure 2013-05-21 11:33 [Qemu-devel] (Another) 1.4.1 -> 1.5.0 migration failure Nicholas Thomas @ 2013-05-21 11:55 ` Andreas Färber 2013-05-21 12:20 ` Nicholas Thomas 2013-05-21 16:55 ` mdroth 1 sibling, 1 reply; 9+ messages in thread From: Andreas Färber @ 2013-05-21 11:55 UTC (permalink / raw) To: Nicholas Thomas; +Cc: qemu-devel, Anthony Liguori, Juan Quintela Hi, Am 21.05.2013 13:33, schrieb Nicholas Thomas: > Migrating from: > > /opt/qemu-1.4.1/bin/qemu-system-x86_64 -M pc -watchdog i6300esb > -watchdog-action reset [...] > > to: > > /opt/qemu-1.5.0/bin/qemu-system-x86_64 -M pc-i440fx-1.4 -watchdog > i6300esb -watchdog-action reset [...] > > I get: > > qemu: warning: error while loading state for instance 0x0 of device > '0000:00:06.0/i6300esb_wdt' > load of migration failed > > Perhaps a similar issue to the network device one? Negative, the watchdog has not undergone anything like the virtio refactorings. Are you using any virtio devices so that device numbering might somehow be different? Andreas > I'm afraid I'm not > sure how to debug these... > > /Nick -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Qemu-devel] (Another) 1.4.1 -> 1.5.0 migration failure 2013-05-21 11:55 ` Andreas Färber @ 2013-05-21 12:20 ` Nicholas Thomas 0 siblings, 0 replies; 9+ messages in thread From: Nicholas Thomas @ 2013-05-21 12:20 UTC (permalink / raw) To: Andreas Färber; +Cc: qemu-devel, Anthony Liguori, Juan Quintela On Tue, 2013-05-21 at 13:55 +0200, Andreas Färber wrote: > Hi, > > Am 21.05.2013 13:33, schrieb Nicholas Thomas: > > Migrating from: > > > > /opt/qemu-1.4.1/bin/qemu-system-x86_64 -M pc -watchdog i6300esb > > -watchdog-action reset [...] > > > > to: > > > > /opt/qemu-1.5.0/bin/qemu-system-x86_64 -M pc-i440fx-1.4 -watchdog > > i6300esb -watchdog-action reset [...] > > > > I get: > > > > qemu: warning: error while loading state for instance 0x0 of device > > '0000:00:06.0/i6300esb_wdt' > > load of migration failed > > > > Perhaps a similar issue to the network device one? > > Negative, the watchdog has not undergone anything like the virtio > refactorings. Are you using any virtio devices so that device numbering > might somehow be different? Virtio networking, discs, and the balloon device too. The full command line looks like this: /opt/qemu-1.4.1/bin/qemu-system-x86_64 -enable-kvm -S -name test -M pc -watchdog i6300esb -watchdog-action reset -smp 1 -m 1024M -L /opt/qemu-1.4.1/share/qemu -balloon virtio -vga cirrus -vnc 127.0.0.1:0, -drive file=nbd:unix:/tmp/vm.test/disc-vda.sock,serial=vda,format=raw,if=virtio -monitor unix:/tmp/vm.test/monitor,server -serial unix:/tmp/vm.test/serial,server,nowait -boot order=ndc -usb -usbdevice tablet -net user,vlan=50,name=user,restrict=y -k en-gb -net nic,model=virtio,macaddr=fe:ff:fe:00:01:64,name=t35600,vlan=896 -net tap,script=no,downscript=no,name=t35600,vlan=896,ifname=t35600 -rtc base=utc,clock=host lspci in the guest on 1.4.1: 00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC [Natoma] (rev 02) 00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II] 00:01.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II] 00:01.2 USB Controller: Intel Corporation 82371SB PIIX3 USB [Natoma/Triton II] (rev 01) 00:01.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03) 00:02.0 VGA compatible controller: Cirrus Logic GD 5446 00:03.0 Ethernet controller: Qumranet, Inc. Device 1000 00:04.0 Unclassified device [00ff]: Qumranet, Inc. Device 1002 00:05.0 SCSI storage controller: Qumranet, Inc. Device 1001 00:06.0 System peripheral: Intel Corporation 6300ESB Watchdog Timer lspci on 1.5.0: 00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC [Natoma] (rev 02) 00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II] 00:01.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II] 00:01.2 USB Controller: Intel Corporation 82371SB PIIX3 USB [Natoma/Triton II] (rev 01) 00:01.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03) 00:02.0 VGA compatible controller: Cirrus Logic GD 5446 00:03.0 Ethernet controller: Qumranet, Inc. Device 1000 00:04.0 Unclassified device [00ff]: Qumranet, Inc. Device 1002 00:05.0 SCSI storage controller: Qumranet, Inc. Device 1001 00:06.0 System peripheral: Intel Corporation 6300ESB Watchdog Timer lspci -vvv on 1.4.1: [...] 00:06.0 System peripheral: Intel Corporation 6300ESB Watchdog Timer Subsystem: Qumranet, Inc. Device 1100 Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Region 0: Memory at febf3000 (32-bit, non-prefetchable) [size=16] lspci -vvv on 1.5.0: [...] 00:06.0 System peripheral: Intel Corporation 6300ESB Watchdog Timer Subsystem: Qumranet, Inc. Device 1100 Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Region 0: Memory at febf3000 (32-bit, non-prefetchable) [size=16] So they seem to be identical from the guest's point of view? /Nick ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Qemu-devel] (Another) 1.4.1 -> 1.5.0 migration failure 2013-05-21 11:33 [Qemu-devel] (Another) 1.4.1 -> 1.5.0 migration failure Nicholas Thomas 2013-05-21 11:55 ` Andreas Färber @ 2013-05-21 16:55 ` mdroth 2013-05-21 17:26 ` mdroth 1 sibling, 1 reply; 9+ messages in thread From: mdroth @ 2013-05-21 16:55 UTC (permalink / raw) To: Nicholas Thomas; +Cc: qemu-devel On Tue, May 21, 2013 at 12:33:38PM +0100, Nicholas Thomas wrote: > Hi all, > > Migrating from: > > /opt/qemu-1.4.1/bin/qemu-system-x86_64 -M pc -watchdog i6300esb > -watchdog-action reset [...] > > to: > > /opt/qemu-1.5.0/bin/qemu-system-x86_64 -M pc-i440fx-1.4 -watchdog > i6300esb -watchdog-action reset [...] > > I get: > > qemu: warning: error while loading state for instance 0x0 of device > '0000:00:06.0/i6300esb_wdt' > load of migration failed > > Perhaps a similar issue to the network device one? I'm afraid I'm not > sure how to debug these... Doesn't look like it, here's a dump of the SaveStateEntry's (i just added some debug statements in vmstate_register_with_alias_id): verison: 1.4.1, se->idstr: timer, se->instance_id: 0 verison: 1.4.1, se->idstr: cpu_common, se->instance_id: 0 verison: 1.4.1, se->idstr: kvm-tpr-opt, se->instance_id: 0 verison: 1.4.1, se->idstr: apic, se->instance_id: 0 verison: 1.4.1, se->idstr: kvmclock, se->instance_id: 0 verison: 1.4.1, se->idstr: fw_cfg, se->instance_id: 0 verison: 1.4.1, se->idstr: PCIBUS, se->instance_id: 0 verison: 1.4.1, se->idstr: 0000:00:00.0/I440FX, se->instance_id: 0 verison: 1.4.1, se->idstr: 0000:00:01.0/PIIX3, se->instance_id: 0 verison: 1.4.1, se->idstr: i8259, se->instance_id: 0 verison: 1.4.1, se->idstr: i8259, se->instance_id: 1 verison: 1.4.1, se->idstr: ioapic, se->instance_id: 0 verison: 1.4.1, se->idstr: 0000:00:02.0/vga, se->instance_id: 0 verison: 1.4.1, se->idstr: hpet, se->instance_id: 0 verison: 1.4.1, se->idstr: mc146818rtc, se->instance_id: 0 verison: 1.4.1, se->idstr: i8254, se->instance_id: 0 verison: 1.4.1, se->idstr: serial, se->instance_id: 0 verison: 1.4.1, se->idstr: ps2kbd, se->instance_id: 0 verison: 1.4.1, se->idstr: ps2mouse, se->instance_id: 0 verison: 1.4.1, se->idstr: pckbd, se->instance_id: 0 verison: 1.4.1, se->idstr: vmmouse, se->instance_id: 0 verison: 1.4.1, se->idstr: port92, se->instance_id: 0 verison: 1.4.1, se->idstr: dma, se->instance_id: 0 verison: 1.4.1, se->idstr: dma, se->instance_id: 1 verison: 1.4.1, se->idstr: fdc, se->instance_id: 0 verison: 1.4.1, se->idstr: 0000:00:01.1/ide, se->instance_id: 0 verison: 1.4.1, se->idstr: i2c_bus, se->instance_id: 0 verison: 1.4.1, se->idstr: 0000:00:01.3/piix4_pm, se->instance_id: 0 verison: 1.4.1, se->idstr: 0000:00:06.0/i6300esb_wdt, se->instance_id: 0 version: 1.5.0, se->idstr: timer, se->instance_id: 0 version: 1.5.0, se->idstr: cpu_common, se->instance_id: 0 version: 1.5.0, se->idstr: cpu, se->instance_id: 0 version: 1.5.0, se->idstr: kvm-tpr-opt, se->instance_id: 0 version: 1.5.0, se->idstr: apic, se->instance_id: 0 version: 1.5.0, se->idstr: kvmclock, se->instance_id: 0 version: 1.5.0, se->idstr: fw_cfg, se->instance_id: 0 version: 1.5.0, se->idstr: PCIBUS, se->instance_id: 0 version: 1.5.0, se->idstr: 0000:00:00.0/I440FX, se->instance_id: 0 version: 1.5.0, se->idstr: 0000:00:01.0/PIIX3, se->instance_id: 0 version: 1.5.0, se->idstr: i8259, se->instance_id: 0 version: 1.5.0, se->idstr: i8259, se->instance_id: 1 version: 1.5.0, se->idstr: ioapic, se->instance_id: 0 version: 1.5.0, se->idstr: 0000:00:02.0/vga, se->instance_id: 0 version: 1.5.0, se->idstr: hpet, se->instance_id: 0 version: 1.5.0, se->idstr: mc146818rtc, se->instance_id: 0 version: 1.5.0, se->idstr: i8254, se->instance_id: 0 version: 1.5.0, se->idstr: serial, se->instance_id: 0 version: 1.5.0, se->idstr: ps2kbd, se->instance_id: 0 version: 1.5.0, se->idstr: ps2mouse, se->instance_id: 0 version: 1.5.0, se->idstr: pckbd, se->instance_id: 0 version: 1.5.0, se->idstr: vmmouse, se->instance_id: 0 version: 1.5.0, se->idstr: port92, se->instance_id: 0 version: 1.5.0, se->idstr: dma, se->instance_id: 0 version: 1.5.0, se->idstr: dma, se->instance_id: 1 version: 1.5.0, se->idstr: fdc, se->instance_id: 0 version: 1.5.0, se->idstr: 0000:00:01.1/ide, se->instance_id: 0 version: 1.5.0, se->idstr: i2c_bus, se->instance_id: 0 version: 1.5.0, se->idstr: 0000:00:01.3/piix4_pm, se->instance_id: 0 version: 1.5.0, se->idstr: 0000:00:06.0/i6300esb_wdt, se->instance_id: 0 Seems like the actual load is failing, but the VMSD hasn't changed so i'm not sure what's going on. > > /Nick > > > ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Qemu-devel] (Another) 1.4.1 -> 1.5.0 migration failure 2013-05-21 16:55 ` mdroth @ 2013-05-21 17:26 ` mdroth 2013-05-21 17:50 ` Peter Maydell 0 siblings, 1 reply; 9+ messages in thread From: mdroth @ 2013-05-21 17:26 UTC (permalink / raw) To: Nicholas Thomas; +Cc: qemu-devel On Tue, May 21, 2013 at 11:55:56AM -0500, mdroth wrote: > On Tue, May 21, 2013 at 12:33:38PM +0100, Nicholas Thomas wrote: > > Hi all, > > > > Migrating from: > > > > /opt/qemu-1.4.1/bin/qemu-system-x86_64 -M pc -watchdog i6300esb > > -watchdog-action reset [...] > > > > to: > > > > /opt/qemu-1.5.0/bin/qemu-system-x86_64 -M pc-i440fx-1.4 -watchdog > > i6300esb -watchdog-action reset [...] > > > > I get: > > > > qemu: warning: error while loading state for instance 0x0 of device > > '0000:00:06.0/i6300esb_wdt' > > load of migration failed > > > > Perhaps a similar issue to the network device one? I'm afraid I'm not > > sure how to debug these... > > Doesn't look like it, here's a dump of the SaveStateEntry's (i just > added some debug statements in vmstate_register_with_alias_id): > > verison: 1.4.1, se->idstr: timer, se->instance_id: 0 > verison: 1.4.1, se->idstr: cpu_common, se->instance_id: 0 > verison: 1.4.1, se->idstr: kvm-tpr-opt, se->instance_id: 0 > verison: 1.4.1, se->idstr: apic, se->instance_id: 0 > verison: 1.4.1, se->idstr: kvmclock, se->instance_id: 0 > verison: 1.4.1, se->idstr: fw_cfg, se->instance_id: 0 > verison: 1.4.1, se->idstr: PCIBUS, se->instance_id: 0 > verison: 1.4.1, se->idstr: 0000:00:00.0/I440FX, se->instance_id: 0 > verison: 1.4.1, se->idstr: 0000:00:01.0/PIIX3, se->instance_id: 0 > verison: 1.4.1, se->idstr: i8259, se->instance_id: 0 > verison: 1.4.1, se->idstr: i8259, se->instance_id: 1 > verison: 1.4.1, se->idstr: ioapic, se->instance_id: 0 > verison: 1.4.1, se->idstr: 0000:00:02.0/vga, se->instance_id: 0 > verison: 1.4.1, se->idstr: hpet, se->instance_id: 0 > verison: 1.4.1, se->idstr: mc146818rtc, se->instance_id: 0 > verison: 1.4.1, se->idstr: i8254, se->instance_id: 0 > verison: 1.4.1, se->idstr: serial, se->instance_id: 0 > verison: 1.4.1, se->idstr: ps2kbd, se->instance_id: 0 > verison: 1.4.1, se->idstr: ps2mouse, se->instance_id: 0 > verison: 1.4.1, se->idstr: pckbd, se->instance_id: 0 > verison: 1.4.1, se->idstr: vmmouse, se->instance_id: 0 > verison: 1.4.1, se->idstr: port92, se->instance_id: 0 > verison: 1.4.1, se->idstr: dma, se->instance_id: 0 > verison: 1.4.1, se->idstr: dma, se->instance_id: 1 > verison: 1.4.1, se->idstr: fdc, se->instance_id: 0 > verison: 1.4.1, se->idstr: 0000:00:01.1/ide, se->instance_id: 0 > verison: 1.4.1, se->idstr: i2c_bus, se->instance_id: 0 > verison: 1.4.1, se->idstr: 0000:00:01.3/piix4_pm, se->instance_id: 0 > verison: 1.4.1, se->idstr: 0000:00:06.0/i6300esb_wdt, se->instance_id: 0 > > version: 1.5.0, se->idstr: timer, se->instance_id: 0 > version: 1.5.0, se->idstr: cpu_common, se->instance_id: 0 > version: 1.5.0, se->idstr: cpu, se->instance_id: 0 > version: 1.5.0, se->idstr: kvm-tpr-opt, se->instance_id: 0 > version: 1.5.0, se->idstr: apic, se->instance_id: 0 > version: 1.5.0, se->idstr: kvmclock, se->instance_id: 0 > version: 1.5.0, se->idstr: fw_cfg, se->instance_id: 0 > version: 1.5.0, se->idstr: PCIBUS, se->instance_id: 0 > version: 1.5.0, se->idstr: 0000:00:00.0/I440FX, se->instance_id: 0 > version: 1.5.0, se->idstr: 0000:00:01.0/PIIX3, se->instance_id: 0 > version: 1.5.0, se->idstr: i8259, se->instance_id: 0 > version: 1.5.0, se->idstr: i8259, se->instance_id: 1 > version: 1.5.0, se->idstr: ioapic, se->instance_id: 0 > version: 1.5.0, se->idstr: 0000:00:02.0/vga, se->instance_id: 0 > version: 1.5.0, se->idstr: hpet, se->instance_id: 0 > version: 1.5.0, se->idstr: mc146818rtc, se->instance_id: 0 > version: 1.5.0, se->idstr: i8254, se->instance_id: 0 > version: 1.5.0, se->idstr: serial, se->instance_id: 0 > version: 1.5.0, se->idstr: ps2kbd, se->instance_id: 0 > version: 1.5.0, se->idstr: ps2mouse, se->instance_id: 0 > version: 1.5.0, se->idstr: pckbd, se->instance_id: 0 > version: 1.5.0, se->idstr: vmmouse, se->instance_id: 0 > version: 1.5.0, se->idstr: port92, se->instance_id: 0 > version: 1.5.0, se->idstr: dma, se->instance_id: 0 > version: 1.5.0, se->idstr: dma, se->instance_id: 1 > version: 1.5.0, se->idstr: fdc, se->instance_id: 0 > version: 1.5.0, se->idstr: 0000:00:01.1/ide, se->instance_id: 0 > version: 1.5.0, se->idstr: i2c_bus, se->instance_id: 0 > version: 1.5.0, se->idstr: 0000:00:01.3/piix4_pm, se->instance_id: 0 > version: 1.5.0, se->idstr: 0000:00:06.0/i6300esb_wdt, se->instance_id: 0 > > Seems like the actual load is failing, but the VMSD hasn't changed so > i'm not sure what's going on. > Ehhh... static const VMStateDescription vmstate_i6300esb = { .name = "i6300esb_wdt", .version_id = sizeof(I6300State), .minimum_version_id = sizeof(I6300State), .minimum_version_id_old = sizeof(I6300State), .fields = (VMStateField []) { VMSTATE_PCI_DEVICE(dev, I6300State), VMSTATE_INT32(reboot_enabled, I6300State), VMSTATE_INT32(clock_scale, I6300State), VMSTATE_INT32(int_type, I6300State), VMSTATE_INT32(free_run, I6300State), VMSTATE_INT32(locked, I6300State), VMSTATE_INT32(enabled, I6300State), VMSTATE_TIMER(timer, I6300State), VMSTATE_UINT32(timer1_preload, I6300State), VMSTATE_UINT32(timer2_preload, I6300State), VMSTATE_INT32(stage, I6300State), VMSTATE_INT32(unlock_state, I6300State), VMSTATE_INT32(previous_reboot_flag, I6300State), VMSTATE_END_OF_LIST() } }; apparently minimum version ID is set the size of the device struct? Almost certain that's the problem. > > > > /Nick > > > > > > ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Qemu-devel] (Another) 1.4.1 -> 1.5.0 migration failure 2013-05-21 17:26 ` mdroth @ 2013-05-21 17:50 ` Peter Maydell 2013-05-21 20:43 ` mdroth 0 siblings, 1 reply; 9+ messages in thread From: Peter Maydell @ 2013-05-21 17:50 UTC (permalink / raw) To: mdroth; +Cc: Juan Quintela, qemu-devel, Nicholas Thomas On 21 May 2013 18:26, mdroth <mdroth@linux.vnet.ibm.com> wrote: > static const VMStateDescription vmstate_i6300esb = { > .name = "i6300esb_wdt", > .version_id = sizeof(I6300State), > .minimum_version_id = sizeof(I6300State), > .minimum_version_id_old = sizeof(I6300State), > apparently minimum version ID is set the size of the device struct? > > Almost certain that's the problem. Haha, yeah, that's totally busted. Interestingly it's been like that since 2009. I think to fix this we probably need to: * set version_id to something fixed but larger than the worst sizeof() has ever been for this device. Since we have plenty of space in an int we might as well set it to 10000. * set minimum_version_id and minimum_version_id_old to 1 [this is safe, I think, since the fields haven't ever changed, but needs testing] * add a big fat comment about why the weird version ID This then brings it into line with everything else, and the standard rules about when to bump vmstate version and marking up new fields with first-version-present and so on all apply as usual. thanks -- PMM ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Qemu-devel] (Another) 1.4.1 -> 1.5.0 migration failure 2013-05-21 17:50 ` Peter Maydell @ 2013-05-21 20:43 ` mdroth 2013-05-21 21:16 ` Peter Maydell 0 siblings, 1 reply; 9+ messages in thread From: mdroth @ 2013-05-21 20:43 UTC (permalink / raw) To: Peter Maydell; +Cc: Juan Quintela, qemu-devel, Nicholas Thomas On Tue, May 21, 2013 at 06:50:23PM +0100, Peter Maydell wrote: > On 21 May 2013 18:26, mdroth <mdroth@linux.vnet.ibm.com> wrote: > > static const VMStateDescription vmstate_i6300esb = { > > .name = "i6300esb_wdt", > > .version_id = sizeof(I6300State), > > .minimum_version_id = sizeof(I6300State), > > .minimum_version_id_old = sizeof(I6300State), > > > apparently minimum version ID is set the size of the device struct? > > > > Almost certain that's the problem. > > Haha, yeah, that's totally busted. Interestingly it's been > like that since 2009. I think to fix this we probably need to: > * set version_id to something fixed but larger than > the worst sizeof() has ever been for this device. > Since we have plenty of space in an int we might as > well set it to 10000. > * set minimum_version_id and minimum_version_id_old to 1 > [this is safe, I think, since the fields haven't ever > changed, but needs testing] > * add a big fat comment about why the weird version ID > > This then brings it into line with everything else, and > the standard rules about when to bump vmstate version > and marking up new fields with first-version-present and > so on all apply as usual. Makes sense, but apparently version IDs for incoming device state are not allowed to exceed the destination's version, so we can't bump it beyond the value in 1.5 without breaking migration from 1.5+ -> 1.5 So I think our only option for version ID is to lock in the 1.5 value, which seems to be 1936 (hopefully that's consistent across builds...). But reseting minimum version ID to 1 does seem to fix 1.4 -> 1.5+ > > thanks > -- PMM > ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Qemu-devel] (Another) 1.4.1 -> 1.5.0 migration failure 2013-05-21 20:43 ` mdroth @ 2013-05-21 21:16 ` Peter Maydell 2013-05-21 22:07 ` mdroth 0 siblings, 1 reply; 9+ messages in thread From: Peter Maydell @ 2013-05-21 21:16 UTC (permalink / raw) To: mdroth; +Cc: Juan Quintela, qemu-devel, Nicholas Thomas On 21 May 2013 21:43, mdroth <mdroth@linux.vnet.ibm.com> wrote: > Makes sense, but apparently version IDs for incoming device state are > not allowed to exceed the destination's version, so we can't bump it > beyond the value in 1.5 without breaking migration from 1.5+ -> 1.5 We care about backwards migration? That sounds like a pain. > So I think our only option for version ID is to lock in the 1.5 value, > which seems to be 1936 (hopefully that's consistent across builds...). Yeah, I'm not convinced that's going to be consistent across builds, compilers, 64 vs 32 bit, etc etc etc. That's why I suggested a really high number. thanks -- PMM ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Qemu-devel] (Another) 1.4.1 -> 1.5.0 migration failure 2013-05-21 21:16 ` Peter Maydell @ 2013-05-21 22:07 ` mdroth 0 siblings, 0 replies; 9+ messages in thread From: mdroth @ 2013-05-21 22:07 UTC (permalink / raw) To: Peter Maydell; +Cc: Nicholas Thomas, qemu-devel, Juan Quintela On Tue, May 21, 2013 at 10:16:48PM +0100, Peter Maydell wrote: > On 21 May 2013 21:43, mdroth <mdroth@linux.vnet.ibm.com> wrote: > > Makes sense, but apparently version IDs for incoming device state are > > not allowed to exceed the destination's version, so we can't bump it > > beyond the value in 1.5 without breaking migration from 1.5+ -> 1.5 > > We care about backwards migration? That sounds like a pain. As a best effort at least, hence subsections and whatnot, but not always. This case for instance... > > > So I think our only option for version ID is to lock in the 1.5 value, > > which seems to be 1936 (hopefully that's consistent across builds...). > > Yeah, I'm not convinced that's going to be consistent across builds, > compilers, 64 vs 32 bit, etc etc etc. That's why I suggested a really > high number. Yah, it's more important to ensure old->new. Playing guessing games about struct sizes to try to maintain new->old is likely to conflict with that, so I guess we don't have much choice here. I'll send a patch out shortly. > > thanks > -- PMM > ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2013-05-21 22:10 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2013-05-21 11:33 [Qemu-devel] (Another) 1.4.1 -> 1.5.0 migration failure Nicholas Thomas 2013-05-21 11:55 ` Andreas Färber 2013-05-21 12:20 ` Nicholas Thomas 2013-05-21 16:55 ` mdroth 2013-05-21 17:26 ` mdroth 2013-05-21 17:50 ` Peter Maydell 2013-05-21 20:43 ` mdroth 2013-05-21 21:16 ` Peter Maydell 2013-05-21 22:07 ` mdroth
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.