Search results

I had a similar issue with Windows 7 and 2008 and the virtoi 0.1.81 drivers on my Dell Servers. After changing everything from virtio to virtio-scsi every Win7 / 2008 machine is stable again.

Perhaps this would help..since Qemu 2.1 implemented PowerManagement features. http://mikebeach.org/2014/05/01/event-id-129-on-windows-server-2012-on-hp-microserver-n40l/

Please don´t use zram on proxmox. This will slowdown the whole system on swap usage. Just put a vm.swappiness = 0 in your /etc/sysctl.conf and reboot the host.

could you please post the pveversion -v command output ?

VirtIO is not emulated so it should be better than the emulated VMXNET3.

Thanks spirit. My bond is working but not the "2" bridges like in the first post. On my production servers I always use 2 bonds, one for management and vzdump and another for the virtual machine traffic. But perhaps I try your bond settings first. The strange thing is, it is working fine with...

Hi, I tried the kernel 3.10.0-4-pve now and the problem still exists. Somehow Mode 4 or 802.3ad is not working with 2 bridges on the same switch. active-backup is working. But if I boot back to 2-6-32-33-pve everything is working fine. What changed in the bond modes in kernel 3.10 ?

I ended up troubleshooting win2k3...I migrated every active directory to zentyal...and every terminal server to win81...so problem´s gone :) mac

OK this works for my cluster for now.

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 ?

good to hear someone also uses similar solutions :)

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

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

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 ?

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

A big thank you also from me. best regards mac

i seen that already, and i used this years ago without the gui. but in this case it is not working. i contacted the manufacturer of thinstuff and they let my reactivate it again....i have to take care of that to my other customers with thinstuff. do you now what happens if you set up a new kvm...

hi spirit, thanks for the hint. in my situation it was another uuid-key related software (thinstuff). the most of the windows vm´s had not to be reactivated.

did you update to no-subscription repo? thereis now qemu-kvm 2.1 inside. and just for testing please try again with the actual 2.6.32-32 kernel.

I have a problem with changing UUID Hardware ID´s with the change qemu.kvm 1.7 to 2.1...is there a change in the vitual bios?...i had to reactivate some windows machines.