Re: [Qemu-devel] Re: Qemu-KVM Livate Migration 0.12.2 -> 0.12.3/4 broken?
Jan Kiszka wrote:
Juan Quintela wrote:
Jan Kiszka wrote:
Juan Quintela wrote:
Lack of "proper" subsections. IDE is something like:
const VMStateDescription vmstate_ide_drive = {
.version_id = 4,
}
static const VMStateDescription vmstate_bmdma = {
.name = "ide bmdma",
.version_id = 4,
...
}
const VMStateDescription vmstate_ide_pci = {
.name = "ide",
.version_id = 4,
VMSTATE_STRUCT_ARRAY(bmdma, PCIIDEState, 2, 0,
vmstate_bmdma, BMDMAState),
VMSTATE_IDE_DRIVES(bus[0].ifs, PCIIDEState),
VMSTATE_IDE_DRIVES(bus[1].ifs, PCIIDEState),
}
Notice that everything is at version 4. It used to be everything at
version 3. Now the problem is that when migrating from v3 -> v4. We
put in one place v3, But we only have a version number at the toplevel,
rest of "subsections" don't sent a version number. There is no way to
fix it in the general case. We can hack something around for ide, but
that will just be a hack, or we can backport marcelo change and port it
as a proper subsection (that is my plan). I expect to have time at the
end of next time to work on this.
BTW, the IDE subsystem is yet lacking a proper vmstate section split-up
along qdev boundaries (ie. vmstate_ide_pci should not contain drive
structures). Do you plan to address this as well?
Not for Friday, and not for 0.12.
For sure. I missed that this was only a 0.12 issue.
That is 0.13 material, and have to get one agreement on how to go.
We can go for:
- good structure
- backward compatibility
I can't see any good way to get both at this stage :( But I am open to
sugestions.
Based on recent experiments with vmstate to enhance the hpet, I'm fairly
optimistic that we can have both (just the code complexity suffers a
bit): Split up the drive sections for new versions, but keep the legacy
fields with attached .field_exists() filters for reading of old
versions. But I may also underestimate issues of this particular case.
Later, Juan.
PD. BTW, very good work with printing the vmstate, that was one of the goals
when we added it, that was the next step after porting everything to
vmstate :)
I'm sorry for stealing you the pleasure to add it. :)
Jan
whats the status of this issue? will migration from 0.12.2 to
0.12.4.1/0.13 work again?
whats the scheduled release dates for 0.12.4.1 and 0.13 (still july 1st) ?
thanks,
peter
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Re: Qemu-KVM Livate Migration 0.12.2 -> 0.12.3/4 broken?
On 17.05.2010, at 11:11, Michael Tokarev wrote: > 17.05.2010 13:07, Juan Quintela wrote: >> Michael Tokarev wrote: > [] >>> http://www.mail-archive.com/kvm@vger.kernel.org/msg34051.html >>> I wonder why it is not noticed before -- it's broken since 0.12... >> >> People has become rich and everybody has a 64 bit hardware :-) > > Actually I don't think there's a CPU that's 32bits and has > necessary VT instructions. At least not the ones to care > about - maybe there were some models but they'e not common > and are gone long time ago. Intel Core Solo / Core Duo (old) Intel Atom z5xx (new) In fact, my mobile KVM development machine is a z530 based notebook. That one's 32-bit only. But then again I have no idea why anyone would need migration there. Alex -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Re: Qemu-KVM Livate Migration 0.12.2 -> 0.12.3/4 broken?
Hi, I can confirm that reverting this patch makes Live Migration from 0.12.2 to 0.12.4 again possible. Br, Peter Juan Quintela wrote: Peter Lieven wrote: Hi Qemu/KVM Devel Team, Live Migration from a 0.12.2 qemu-kvm to a 0.12.3 (and 0.12.4) does not work: "load of migration failed" Is there any way to find out, why exactly it fails? I have a lot of VMs running on 0.12.2 and would like to migrate them to 0.12.4 cmdline: -net tap,vlan=6,script=no,downscript=no,ifname=tap7 -net nic,vlan=6,model=e1000,macaddr=52:54:00:fe:00:88 -net tap,vlan=651,script=no,downscript=no,ifname=tap8 -net nic,vlan=651,model=e1000,macaddr=52:54:00:ff:00:69 -drive file=/dev/mapper/iqn.2001-05.com.equallogic:0-8a0906-b6eca7604-6280020bc4b4bde8-quagga,if=ide,boot=on,cache=none,aio=native -m 256 -monitor tcp:0:4090,server,nowait -vnc :90 -name 'Quagga' -boot order=dc,menu=on -k de -incoming tcp:172.21.59.132:5090 -pidfile /var/run/qemu/vm-148.pid -rtc base=utc,clock=vm -usb -usbdevice tablet -no-kvm-irqchip -vga cirrus Any hints would be appreciated! Can you try reverting this patch? commit 3fa017e24b0a0f0e68619a689b9b02fe486dae9e Author: Marcelo Tosatti Date: Thu Feb 11 18:19:44 2010 -0200 ide save/restore pio/atapi cmd transfer fields and io buffer and told me if it works? Later, Juan. -- Mit freundlichen Grüßen/Kind Regards Peter Lieven .. KAMP Netzwerkdienste GmbH Vestische Str. 89-91 | 46117 Oberhausen Tel: +49 (0) 208.89 402-50 | Fax: +49 (0) 208.89 402-40 mailto:p...@kamp.de | http://www.kamp.de Geschäftsführer: Heiner Lante | Michael Lante Amtsgericht Duisburg | HRB Nr. 12154 USt-Id-Nr.: DE 120607556 . -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
