[Users] After upgrade of ovirt > 3.3 all Windows vms lost their activation against Microsoft

[Michal Skrivanek]

On 25 Feb 2014, at 08:32, Ayal Baron wrote:

> Michal, please see inline
> 
> ----- Original Message -----
>> ----- Original Message -----
>>> From: "R P Herrold" <herrold at owlriver.com>
>>> To: "Ricky Schneberger" <ricky at schneberger.se>
>>> Cc: users at ovirt.org
>>> Sent: Monday, February 24, 2014 6:42:54 PM
>>> Subject: [Users] After upgrade of ovirt > 3.3 all Windows vms lost their
>>> activation against Microsoft
>>> 
>>> On Mon, 24 Feb 2014, Ricky Schneberger wrote:
>>> 
>>>>> Why is the Windows VMs always lost their activation against Microsoft
>>>>> after that I have upgrade ovirt?
>>> ...
>>>> Yes I am sure its related to the upgrade.

only upgrade, not a specific VM run? In other words it doesn't check the BIOS serial number since that's different on each hypervisor.

>>>> 
>>>> In the application log of the VM we can see  "hardware has changed from
>>>> previous boot" and also we have a licensing system on another host that
>>>> got in a stucked state because of the same reason - "hardware has
>>>> changed from previous boot".
>>> 
>>> I see the following discussions ... changes in bios, or
>>> hardware device numbers, seem to trigger this
>>> 
>>> (Citrix instances)
>>> http://support.citrix.com/article/CTX135542
>>> 
>>> http://support.citrix.com/article/CTX132220/
>>> 
>>> http://discussions.citrix.com/topic/313096-windows-activation-license-mak-used/#entry1674492
>>> 
>>> http://answers.microsoft.com/en-us/windows/forum/windows_7-windows_install/windows-7-activation-always-come-back-after/b26f8338-ae51-44d1-a0d9-b3a71643548a
>>> 
>>> So the issue may in some cases be avoided, but in others, will
>>> need oVirt attention to not changing values refered to by the
>>> licensing validation code.  Identifying all those test point
>>> valuess so they may be preserved, looks like something the
>>> upstream (commercial) vendor would not be very interesting in
>>> revealing as it would impact their revenue model, so it
>>> probably needs a set of 'reproducers' identified, and test
>>> cases written ...
>> 
>> I think the best solution would be if Microsoft would send some patches :-)
>> 
>> Ricky, would you open a bug so we can track this issue?
> 
> oVirt tries to keep stable device addresses (e.g. pci slot) specifically to prevent this issue.
> The way it is done is that after running the VM we query libvirt for all the device addresses and on next run we provide libvirt with the same addresses to keep the devices from changing.
> This feature was not available in 3.0 so I see 2 options here:
> 1. this VM was not started (or was running) since 3.0
> 2. introduction of new virtual hardware caused a change in the device addresses for some reason (bug).

in addition to stable PCI addresses, new QEMU/KVM release sometimes change the system hardware - emulated machine mode.
or if it is really subtle, it can also be triggered by new devices (e.g. balloon, virtio-console (used to be in 3.0, removed in 3.1, optional in 3.3)) or simple upgrade of virtio drivers

anyway, so what changes in devices you can see after upgrade? 

Thanks,
michal

> 
> Anyway, adding Michal who is more familiar with this part than I.
> 
> 
>> 
>> Nir
>> _______________________________________________
>> Users mailing list
>> Users at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/users
>>