[libvirt-users] os/type/machine/pc-xxxx meaning ? following live migration issue after an upgrade
Dear All, I have upgrade my hypervisors: qemu-kvm 0.12.5 => 1.1.2 libvirt-bin 0.8.3-5 => 0.9.12.3 (debian6 to debian7) After that upgrade, i noticed that live migration was most of the time failing (freeze) (not always) I also noticed that creating a machine with the updated hypervisor was always working. After some days of investigation mainly on network side, i found this setting that seems to fix the issue in the xml: <os> <type arch='x86_64' machine='pc-0.12'>hvm</type> <boot dev='hd'/> </os> replacing pc-0.12 with pc-1.1 seems to fix the issue. Here are my questions : 1) what is the meaning/purpose of that setting ? (i guess it is somehow linked to the version of kvm ;) ) 2) can i just change it in all xmls ? ( i have plenty of linux/windows flavors running in my vms) 3) is it possible to put a more generic value? So we don't have the same issue on next upgrade. 4) Is there a script/doc that explains what needs to be done on the vm itself (xml or other) when we upgrade libvirt/kvm ? Thanks for the feedback ! Benoit. -- Benoit Rousselle
On Fri, Jul 04, 2014 at 11:04:53AM +0200, Benoit Rousselle wrote:
Dear All,
I have upgrade my hypervisors: qemu-kvm 0.12.5 => 1.1.2 libvirt-bin 0.8.3-5 => 0.9.12.3 (debian6 to debian7)
After that upgrade, i noticed that live migration was most of the time failing (freeze) (not always) I also noticed that creating a machine with the updated hypervisor was always working.
After some days of investigation mainly on network side, i found this setting that seems to fix the issue in the xml:
<os> <type arch='x86_64' machine='pc-0.12'>hvm</type> <boot dev='hd'/> </os>
replacing pc-0.12 with pc-1.1 seems to fix the issue.
Here are my questions : 1) what is the meaning/purpose of that setting ? (i guess it is somehow linked to the version of kvm ;) )
It encodes a specific guest machine ABI.
2) can i just change it in all xmls ? ( i have plenty of linux/windows flavors running in my vms)
If you change it, the guest machine ABI will have changes. Usually fairly minor, but changes none the less. This is not a problem for most guest OS. Sometimes though, a change will be enough to cause Windows to want todo license re-activation.
3) is it possible to put a more generic value? So we don't have the same issue on next upgrade.
We use a fixed version in an attempt to prevent windows re-activation.
4) Is there a script/doc that explains what needs to be done on the vm itself (xml or other) when we upgrade libvirt/kvm ?
Not really. If you don't mind the risk of Windows re-activation then just delete the machine attribute and libvirt will re-add it using the newest machine type version. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
Thanks for the quick answer :D 2 more questions: - what is the exact meaning of ABI ? - Can you explain why live migration was failing pc-0.12 on kvm 1.1 ? Thanks, Benoit. On Fri 04 Jul 2014 11:10:57 AM CEST, Daniel P. Berrange wrote:
On Fri, Jul 04, 2014 at 11:04:53AM +0200, Benoit Rousselle wrote:
Dear All,
I have upgrade my hypervisors: qemu-kvm 0.12.5 => 1.1.2 libvirt-bin 0.8.3-5 => 0.9.12.3 (debian6 to debian7)
After that upgrade, i noticed that live migration was most of the time failing (freeze) (not always) I also noticed that creating a machine with the updated hypervisor was always working.
After some days of investigation mainly on network side, i found this setting that seems to fix the issue in the xml:
<os> <type arch='x86_64' machine='pc-0.12'>hvm</type> <boot dev='hd'/> </os>
replacing pc-0.12 with pc-1.1 seems to fix the issue.
Here are my questions : 1) what is the meaning/purpose of that setting ? (i guess it is somehow linked to the version of kvm ;) )
It encodes a specific guest machine ABI.
2) can i just change it in all xmls ? ( i have plenty of linux/windows flavors running in my vms)
If you change it, the guest machine ABI will have changes. Usually fairly minor, but changes none the less. This is not a problem for most guest OS. Sometimes though, a change will be enough to cause Windows to want todo license re-activation.
3) is it possible to put a more generic value? So we don't have the same issue on next upgrade.
We use a fixed version in an attempt to prevent windows re-activation.
4) Is there a script/doc that explains what needs to be done on the vm itself (xml or other) when we upgrade libvirt/kvm ?
Not really. If you don't mind the risk of Windows re-activation then just delete the machine attribute and libvirt will re-add it using the newest machine type version.
Regards, Daniel
On Fri, Jul 04, 2014 at 11:22:13AM +0200, Benoit Rousselle wrote:
Thanks for the quick answer :D
2 more questions: - what is the exact meaning of ABI ?
Any aspect of the hardware that is visible to the guest. eg IRQ numbers, I/O ports, memory ranges, PCI config spec values, etc, etc.
- Can you explain why live migration was failing pc-0.12 on kvm 1.1 ?
Well there have certainly been bugs in the past, so I presume you've been unlucky to hit one. Usually /var/log/libvirt/qemu/$NAME.log on the target host tells you what failed, at which point the QEMU developers might be able to help. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
participants (2)
-
Benoit Rousselle -
Daniel P. Berrange