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

Michal, please see inline ----- Original Message ----- > ----- Original Message ----- >> From: "R P Herrold" <herrold(a)owlriver.com&gt; >> To: "Ricky Schneberger" <ricky(a)schneberger.se&gt; >> Cc: users(a)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.

>>> >>> 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... >> >> http://answers.microsoft.com/en-us/windows/forum/windows_7-windows_instal... >> >> 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).

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