libvirt users - Jul 2014 - 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