ProxMox 3.2 to 3.3, impressions and a problem

[withervoice]

So I've started the upgrade process to take our nodes from 3.2 to 3.3, and thus far, I have a few impressions to share.

• noVNC performs markedly faster than VNC over medium-to-long network distances/remote tunnels
• upgrade process was quick and painless (as expected)
• the system as a whole shows a small, but distinct, performance improvement

One problem we've had, though, is that a lot of our Windows-based VMs, but disturbingly not ALL, have deactivated their Windows licencing after the upgrade. Microsoft are going to be receiving 3.7 metric tonnes of calls from us, trying to reactivate them all... so. My question as to this problem would, I guess, be: is there any way we can avoid that problem? Short of not upgrading, which isn't really to be considered a viable option... the improved performance is just TOO worth it.

 

[mir]

Maybe caused by the upgrade of qemu?

You cannot blame Proxmox for Microsoft's broken license registration algorithm in Windows. I suggest your address your complain to your local windows dealer.

 

[withervoice]

Maybe caused by the upgrade of qemu?

You cannot blame Proxmox for Microsoft's broken license registration algorithm in Windows. I suggest your address your complain to your local windows dealer.

Personally, I feel that my question about ways to mitigate a given problem falls far short of being either a complaint or an accusation of any fault; I simply figured it was vastly more likely that a given user of ProxMox had found a workaround they might be willing to share, than that anyone associated with Microsoft had.

Your analysis of the likely root of the problem mirrors mine perfectly.

 

[spirit]

The problem could be the qemu upgrade from 1.7 to 2.1 . (maybe something in the virtual motherboard of qemu have changed, and windows don't like that for licensing).



maybe can you try to add in your vmid.conf

machine: pc-i440fx-1.7




(I'm personnaly use volume licenses and I never had this kind of licensing problem)

 

[macday]

A possible solution would be: Before upgrading to 3.3 generate and use UUID for the M$ VM´s.

http://www.mono-software.com/blog/post/Mono/142/Setting-hardware-UUID-in-Hyper-V-and-ProxMox/

but I have to test it though.

cheers
mac

 

[spirit]

note that proxmox 3.3 support uuid and generate one by default at vm create.


vmid.conf
---------
smbios1: uuid=df979e78-692d-45c8-a055-bf1b15b699fa

 

[macday]

yes your right...but you need to create a uuid before your switch to 3.3...so howto generate a uuid? i found this here http://www.famkruithof.net/uuid/uuidgen but the uuid in windows is different than this generated. or what elese step by step solution would help us proxmox users ?

 

[aderumier]

yes, uuid is a standard format, you can use this generator.


I'm not sure, but qemu-kvm don't expose any uuid by default.

can you check in windows with:

wmic csproduct get name,identifyingnumber,uuid
(see doc here : http://www.nextofwindows.com/how-to-find-out-bios-motherboard-and-cpu-info-from-command-line/)


Then, on proxmox 3.2, add

args: .... with uuid.

(and stop/start the vm)

 

[m.ardito]

Hi,

would anyone be so kind to elaborate a bit more clearly this "uuid & windows licenses" issue and how can one manage this before converting the underlying qemu version?
I don't get it... but I could need to.

Thanks,
Marco

 

[macday]

it is probably not working for all windows installs since qemu 2.1 changes too much "hardware" so if you put the uuid there is still a chance that windows screams for reactivation.

a good thing is that from now on (3.3) created machines always generate fresh uuids.

i have also many windows 7 oem installations which have to reactivated per telephone....this much work keeps me away from updating some hosts
i haven´t tried the machine: pc-i440fx-1.7 switch yet. hope this works.

 

[vmanz]

Hi,

I have another issue related to the "hardware" changes.

besides reactivation of win7pro, some other software has a licence problem. So think about twice about upgrade.

proxmox is a very great tool and perhaps you may forget about the proprietary stuff running on it.

Hope it helps,

 

[macday]

Hi,

I have another issue related to the "hardware" changes.

besides reactivation of win7pro, some other software has a licence problem. So think about twice about upgrade.

proxmox is a very great tool and perhaps you may forget about the proprietary stuff running on it.

Hope it helps,

For me also. My software is called Thinstuff. I already opened a ticket on this at Thinstuff and they told me what causes that reactivation. It is the "hardware" sequence from the nic´s. So if the sqeuence changes this causes a reactivation. this is true if you also have just one nic.

This is ok for small businesses but for big companies this could be a showstopper.

 

[vmanz]

Hi macday, This is the product I was talking about - wouldn't call it by name.

 

[macday]

Hi macday, This is the product I was talking about - wouldn't call it by name.

good to hear someone also uses similar solutions

 

[spirit]

It is the "hardware" sequence from the nic´s. So if the sqeuence changes this causes a reactivation. this is true if you also have just one nic.

In proxmox, all devices are assigned by virtual pci slots (like a read motherboard), so the order never change.
Only difference could be in qemu 2.1, something related to virtual motherboard chipsets or something like that.

What is your windows version ? (oem ? retail ?).
I would like to test, because I have only volume licenses here.

 

[mir]

I have a win7 pro here all though part of a volume license program (using licensing server at work) but requires that you enter a license manually at home. This installation did not require a reactivation.

 

[macday]

In proxmox, all devices are assigned by virtual pci slots (like a read motherboard), so the order never change.
Only difference could be in qemu 2.1, something related to virtual motherboard chipsets or something like that.

What is your windows version ? (oem ? retail ?).
I would like to test, because I have only volume licenses here.

Hi Spirit,

it is a Win7x64 OEM. If my time allows I will also make tests with the pc-i440fx-1.7 switch.

Can someone tell me what this switch does. Am I lackin some qemu 2.1 features with this ?

 

[vmanz]

hi macday, hi spirit,

the pc-440fx-1.7 line didn't do the trick for me.

I use W7pro system-builder versions.


I'm actually restore my backups from bevore upgrade to a pve 3.2 machine - THE LICENCE IS VALID

can probably someone tell me on the short way how to upgrade the last PVE 3.2 to the latest 3.2 without running into PVE 3.3 again. Please don't tell me use the forum-search, I had only 3h time for bed tonight.

Greets an thanks,

 

[spirit]

what you could try is too keep pve-qemu-kvm 1.7 and upgrade all other proxmox packages to 3.3


# apt-mark hold pve-qemu-kvm

then
# apt-get update
# apt-get dist-upgrade

 

[term]

So, this is the proposed solution?

1. Before upgrading, go to each windows VM. Run "wmic csproduct get uuid" from the command line and record the uuid.
2. Go to every windows VM conf file and add this: smbios1: uuid=your uuid from step 1 (config files are stored at /etc/pve/nodes/nodename/qemu-server/)
3. Now, its safe to upgrade to proxmox 3.3.

Will the old qemu simply ignore the smbios1: configuration setting, or will it cause an error?

EDIT: No, this doesn't work. As noted above, KVM does not appear to expose machine UUID. Or the UUID is really all zeros. Running "info uuid" from the monitor returns all zeros as well.