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

Tue Feb 25 08:39:05 UTC 2014

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2014-02-25 08:51, Michal Skrivanek wrote:
> 
> 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

It was running just until the upgrade to ovirt 3.2 and then the VM was
test started before the upgrade to ovirt 3.3. If the license issue
came between 3.1>3.2 or between 3.2>3.3 I right dont know.

>> 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?
> 

It seems that a changes in the display system triggered the Software
Protection service.
When I check the logs I can see there was and upgrade/change/new
install of drivers to the display adapter. I dont know if I got a new
PCI address, but when I checked a VM that does not triggered the
Software Protection service I cannot find such things in the loggfiles.

So in one way or another the VM think there was changes big enough to
hit the Software Protection service.

> 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
>>> 
> 
> _______________________________________________ Users mailing list 
> Users at ovirt.org http://lists.ovirt.org/mailman/listinfo/users
> 

Regards
- -- 
Ricky Schneberger

- ------------------------------------
"Not using free exhaust energy to help your engine breathe is
downright criminal"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlMMVqkACgkQOap81biMC2Mm4ACfVcVH6smXm06sj+XNbmRuaYza
cUAAoIoA7TOXJQyLsFk58/KqlJBtP/qY
=R8Zj
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xB88C0B63.asc
Type: application/pgp-keys
Size: 8073 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/users/attachments/20140225/b204e305/attachment-0001.bin>