[Qemu-devel] qemu version updates break Windows activation

[Qemu-devel] qemu version updates break Windows activation

[Frederik Himpe]

Every time qemu/kvm is updated, the version strings in the virtual 
hardware change, which breaks an activated windows installation in qemu. 
Windows thinks it's running on other hardware, and requires manual re-
activation by phone.

Could the version strings please be made optional in the hardware?

See also http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=467043

-- 
Frederik Himpe

Re: [Qemu-devel] qemu version updates break Windows activation

[Jamie Lokier]

Frederik Himpe wrote:
> Every time qemu/kvm is updated, the version strings in the virtual 
> hardware change, which breaks an activated windows installation in qemu. 
> Windows thinks it's running on other hardware, and requires manual re-
> activation by phone.
> 
> Could the version strings please be made optional in the hardware?
> 
> See also http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=467043

Does Windows also break whenever you do a firmware update on a real
machine?

-- Jamie

Re: [Qemu-devel] qemu version updates break Windows activation

[Paul Brook]

On Wednesday 26 November 2008, Jamie Lokier wrote:
> Frederik Himpe wrote:
> > Every time qemu/kvm is updated, the version strings in the virtual
> > hardware change, which breaks an activated windows installation in qemu.
> > Windows thinks it's running on other hardware, and requires manual re-
> > activation by phone.
> >
> > Could the version strings please be made optional in the hardware?
> >
> > See also http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=467043
>
> Does Windows also break whenever you do a firmware update on a real
> machine?

Yes, if the new firmware causes the device to report itself slightly 
differently. I've seen this happen when upgrading real drive firmwares.

Paul

Re: [Qemu-devel] qemu version updates break Windows activation

[Stefano Stabellini]

Jamie Lokier wrote:

> Frederik Himpe wrote:
>> Every time qemu/kvm is updated, the version strings in the virtual 
>> hardware change, which breaks an activated windows installation in qemu. 
>> Windows thinks it's running on other hardware, and requires manual re-
>> activation by phone.
>>
>> Could the version strings please be made optional in the hardware?
>>
>> See also http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=467043
> 
> Does Windows also break whenever you do a firmware update on a real
> machine?
> 

Of course it does :)

Re: [Qemu-devel] qemu version updates break Windows activation

[Avi Kivity]

Frederik Himpe wrote:
> Every time qemu/kvm is updated, the version strings in the virtual 
> hardware change, which breaks an activated windows installation in qemu. 
> Windows thinks it's running on other hardware, and requires manual re-
> activation by phone.
>
> Could the version strings please be made optional in the hardware?
>
>   

Perhaps we should switch the version strings not to include the qemu 
version, but instead carry their own version numbers, which would bump 
on on incompatible change (presumably, never).

-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] qemu version updates break Windows activation

[Jamie Lokier]

Avi Kivity wrote:
> Frederik Himpe wrote:
> >Every time qemu/kvm is updated, the version strings in the virtual 
> >hardware change, which breaks an activated windows installation in qemu. 
> >Windows thinks it's running on other hardware, and requires manual re-
> >activation by phone.
> >
> >Could the version strings please be made optional in the hardware?
> >
> >  
> 
> Perhaps we should switch the version strings not to include the qemu 
> version, but instead carry their own version numbers, which would bump 
> on on incompatible change (presumably, never).

Microsoft Virtual PC lets you override the version strings and UUIDs
yourself for some things, I think.  They are in the XML VM description
file, which is what you click on start a VM.

This is helpful for moving existing VM images from one hypervisor to
another without needing Windows re-activation.  VMware probably does
the same, to be able to run Virtual PC images unchanged.

-- Jamie

Re: [Qemu-devel] qemu version updates break Windows activation

[Ben Taylor]

On Thu, Nov 27, 2008 at 9:47 AM, Jamie Lokier <jamie@shareable.org> wrote:
> Avi Kivity wrote:
>> Frederik Himpe wrote:
>> >Every time qemu/kvm is updated, the version strings in the virtual
>> >hardware change, which breaks an activated windows installation in qemu.
>> >Windows thinks it's running on other hardware, and requires manual re-
>> >activation by phone.
>> >
>> >Could the version strings please be made optional in the hardware?
>> >
>> >
>>
>> Perhaps we should switch the version strings not to include the qemu
>> version, but instead carry their own version numbers, which would bump
>> on on incompatible change (presumably, never).
>
> Microsoft Virtual PC lets you override the version strings and UUIDs
> yourself for some things, I think.  They are in the XML VM description
> file, which is what you click on start a VM.
>
> This is helpful for moving existing VM images from one hypervisor to
> another without needing Windows re-activation.  VMware probably does
> the same, to be able to run Virtual PC images unchanged.

Being to set a bios string may also allow things like recovery disks
to be used in qemu (My HP recovery disks only boot on the system
it's built for, via a bios string - I discovered this while trying to make
it partition the disk differently during the restore).

Re: [Qemu-devel] qemu version updates break Windows activation

[Daniel P. Berrange]

On Thu, Nov 27, 2008 at 04:38:34PM +0200, Avi Kivity wrote:
> Frederik Himpe wrote:
> >Every time qemu/kvm is updated, the version strings in the virtual 
> >hardware change, which breaks an activated windows installation in qemu. 
> >Windows thinks it's running on other hardware, and requires manual re-
> >activation by phone.
> >
> >Could the version strings please be made optional in the hardware?
> >
> >  
> 
> Perhaps we should switch the version strings not to include the qemu 
> version, but instead carry their own version numbers, which would bump 
> on on incompatible change (presumably, never).

This sounds like a good idea. If a guest really badly wants to know the
QEMU version number, it is already exposed via the SMBIOS data tables,
so its redundant to include in the per-device info too.

NB, this doesn't just impact Windows - when configuring evdev in Linux
it is desirable to configure it to match based on device name, rather
than the unstable path /dev/input/event3. This is only possible if the
device name is stable though, so removing the QEMU version number would
help make more reliable Linux Xorg configs too.

Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|