Running Windows under Linux KVM
Task: run a number of virtual machines with Windows on a typical Linux server.
Solution: any modern Linux distribution, native KVM virtualization technology, Windows 2003 and the settings described below.
See also: introduction to the KVM container configuration for FreeBSD .
Windows XP does not work well under Linux KVM. The main errors are the consumption of 100% of the processor by the csrss.exe process (up to the termination of the RDP sessions) and the BSOD with the code IRQL_NOT_LESS_OR_EQUAL in HAL.DLL. If you managed to achieve stable operation, be sure to disable the automatic installation of updates! In our experience, for running WinXP under KVM, they became the main source of problems.
')
Windows 7 is working fine, but according to Proxmox counters, it requires more than 3 gigabytes of RAM to run.
The best option was the 32-bit edition of Windows 2003 R2:
The upper limit of 4 gigabytes of memory (without PAE) was enough for all the arising problems.
For familiarization purposes, any distribution published on RuTracker is suitable.
The "-vnc ..." option only makes sense on a server without a GUI. By default, KVM will open the window via SDL. In both cases, Ctrl + Alt + Shift + 1 and Ctrl + Alt + Shift + 2 are used to switch inside the window between the guest console and the control console.
The "
Now about the most important thing at this stage, i.e. about the wheels.
HDC is an ISO image with a Windows distribution. The file name is taken from the torrent in the previous section. From there inside the VM, the first system boot will occur ("
HDD is an ISO image with virtio drivers. Downloading from alt.fedoraproject.org/pub/alt/virtio-win/latest/images/bin
HDA is an empty disk image on which the system will be installed. Created by the command "
HDB is an empty disk image created through "
After the installation of the system and drivers is complete, the start command should remove the "-boot" and all the lines "-drive" except the first, because the temporary disk and ISO images will not be needed (note the added "
For the benefit of virtio, network configuration options and command line parameters kvm read habrahabr.ru/post/167099
First, by default, Windows creates a complete memory dump under BSODs. At best, this will significantly slow down the reboot. At worst, it will lead to a complete freeze.
Secondly, automatic updates are enabled by default, and there is a risk that one of them will make the work under KVM unstable.
Therefore, after the installation is completed in the very first place (before installing the drivers!), It is recommended to enter the Control Panel => System:
TCP / IP settings are optional, but will improve performance a bit, because In a virtual environment, there are some problems that need to be taken into account when transmitting over a physical network.
Description: www.linux-kvm.org/page/WindowsGuestDrivers/kvmnet/registry
Ready REG file: svn1.sytes.net/linuxkvm/tune-guest-tcpip.reg
After that, you can install drivers for the disk (virt-stor) and the network card (virt-net). After installing them, the Red Hat VirtIO SCSI Controller, Red Hat VirtIO SCSI Disk Device and Red Hat VirtIO Ethernet Adapter will appear in the Hardware Manager.
The traditional approach is to immediately allocate a block of RAM of a given size, for example, 512 megabytes, immediately when the virtual machine (VM) starts up. Its disadvantage is in those moments when there is unused space in the VM memory, in other VMs and in the host system it may not be enough.
Memory ballooning is a mechanism for dynamically (a) allocating a host RAM for a VM as needed and (b) returning unused blocks as it is released. Thanks to him, it becomes possible to simultaneously run multiple VMs, the total amount of virtual RAM in which there is more physical RAM in the host system, provided that they do not use the maximum allowed volume all at once. Due to this, the host system memory is distributed between VMs as flexibly as between normal processes.
The creation of virtual resources that exceed the physical in terms of volume is indicated by the terms “overcommit” and “overselling” that are favorite to many hosters.
The operation of the ballooning requires the coordinated operation of two software components:
MOM in the latest versions of KVM is turned on automatically, the old ones required to enable it using "kvm ... -balloon virtio" on the command line.
The guest device for communicating with the MOM Hardware Controller (devmgmt.msc) will be seen by Windows as an “PCI standard RAM controller” of unknown type. Unlike virt-stor and virt-net, the driver for it will not be offered to be installed automatically. Instead, go to the properties of the device, on the Driver tab, select the update and manually specify the path to balloon.inf on the VirtIO CD ( proof ). After that, the device will be renamed “VirtIO Balloon Driver”.
By default, Windows 2003 allows you to turn yourself off in the only way - enter your login and password, select Start => “Shut down”, enter a note, click “OK”. Of course, this approach is unacceptable on a VDS farm. KVM (and QEMU) can emulate ACPI. The “system_powerdown” command is similar to pressing the power button on a physical computer, but Windows will ignore it. It is treated with the following .reg file:
He is ready to run: svn1.sytes.net/linuxkvm/win-acpi-kvm.reg
Original source with detailed explanations: umgum.com/acpi-windows2003-shutdown
If a guest disk image is stored on a VDS farm as a file, guest file caching can be doubled: first, the guest OS caches them when accessing the virtual disk, then the farm OS when accessing the physical one.
In total there are 3 main modes :
Different versions of qemu / kvm and different operating systems can use different modes by default. For example, Qemu up to version 1.2 uses writethrough, 1.2 switched to writeback, cache = none is selected in Proxmox.
All sources on the Web, without exception, advise not to use writethrough as the slowest. According to a subjective assessment, writeback is optimal for Windows VMs, none is for Linux VMs and FreeBSD VMs.
The only serious problem that the error in KVM unambiguously causes is the hang of the guest network during heavy traffic: bugs.centos.org/view.php?id=5526 (besides the description of the error, there are also important links to other bug trackers).
The recommendations offered by the participants in the discussions (updating qemu-kvm and the kernel, changing the command line parameters, using vhost-net), unfortunately, have not yet been able to solve it.
With each hang, you have to go to the VM console via VNC and reset the network interface, after which the traffic starts walking again normally.
To automate this action in Windows, you can use AutoIt, if you create the file PingFailed_ResetNic.au3 and call it Task Manager every few minutes:
Option for CMD.EXE: rickosborne.org/blog/2007/02/stupid-windows-tricks-restart-network-adapter-when-it-hangs
Such a “solution” may not be considered satisfactory everywhere, but in some cases it is enough to reduce the negative effect to an acceptable minimum, allowing one to wait for the release of the correction instead of more drastic measures.
Solution: any modern Linux distribution, native KVM virtualization technology, Windows 2003 and the settings described below.
See also: introduction to the KVM container configuration for FreeBSD .
Guest OS selection
Windows XP does not work well under Linux KVM. The main errors are the consumption of 100% of the processor by the csrss.exe process (up to the termination of the RDP sessions) and the BSOD with the code IRQL_NOT_LESS_OR_EQUAL in HAL.DLL. If you managed to achieve stable operation, be sure to disable the automatic installation of updates! In our experience, for running WinXP under KVM, they became the main source of problems.
')
Windows 7 is working fine, but according to Proxmox counters, it requires more than 3 gigabytes of RAM to run.
The best option was the 32-bit edition of Windows 2003 R2:
- works reliably, incl. with virtio,
- There are no compatibility issues with XP (even the appearance can be made the same ),
- occupies less than 800 megabytes of RAM.
The upper limit of 4 gigabytes of memory (without PAE) was enough for all the arising problems.
For familiarization purposes, any distribution published on RuTracker is suitable.
First run and virtio
#!/bin/sh VM_ID="10" MACBASE="00:16:3e:ff:ff" HDA="vm_${VM_ID}.img" HDB="temp.img" HDC="w2k3_r2_ent_rus_x86/ru_win_srv_2003_r2_enterprise_with_sp2_vl_cd1_X13-46484.iso" HDD="virtio-win-0.1-52.iso" sudo kvm \ -enable-kvm \ -boot "menu=on,order=d" \ -m 1024M \ -balloon virtio \ -name "kvm_${VM_ID}" \ -drive "file=$HDA,index=0,media=disk,cache=writeback" \ -drive "file=$HDB,index=1,media=disk,cache=writeback,if=virtio" \ -drive "file=$HDC,index=2,media=cdrom,cache=writeback,readonly" \ -drive "file=$HDD,index=3,media=cdrom,cache=writeback,readonly" \ -net "nic,model=virtio,macaddr=${MACBASE}:${VM_ID}" \ -net "tap,ifname=tap${VM_ID},script=no,downscript=no" \ -vnc "0.0.0.0:${VM_ID}" The "-vnc ..." option only makes sense on a server without a GUI. By default, KVM will open the window via SDL. In both cases, Ctrl + Alt + Shift + 1 and Ctrl + Alt + Shift + 2 are used to switch inside the window between the guest console and the control console.
The "
-net nic,model=virtio,... " -net nic,model=virtio,... will create inside the VM a network card of unknown Windows type for which the hardware setup wizard will prompt you to select a driver. The paired parameter " -net tap,... " will create in the host OS a network interface for communicating with the VM. Assigning IP addresses, configuring DHCP and accessing the outside world through ProxyARP, NAT or Bridge are not directly related to Windows, so they are not considered here.Now about the most important thing at this stage, i.e. about the wheels.
HDC is an ISO image with a Windows distribution. The file name is taken from the torrent in the previous section. From there inside the VM, the first system boot will occur ("
-boot order=d ").HDD is an ISO image with virtio drivers. Downloading from alt.fedoraproject.org/pub/alt/virtio-win/latest/images/bin
HDA is an empty disk image on which the system will be installed. Created by the command "
kvm-img create -f qcow2 vm_10.img 50G ".HDB is an empty disk image created through "
kvm-img create -f qcow2 temp.img 1G " for the sole purpose of showing the Windows device of an unknown type, so that it would request a driver for it. Installing the virtio driver for the temporary disk into the system will then allow you to switch the system disk from IDE to virtio.After the installation of the system and drivers is complete, the start command should remove the "-boot" and all the lines "-drive" except the first, because the temporary disk and ISO images will not be needed (note the added "
if=virtio "!): kvm ... -drive "file=$HDA,index=0,media=disk,cache=writeback,if=virtio" ... For the benefit of virtio, network configuration options and command line parameters kvm read habrahabr.ru/post/167099
Recommended Windows Settings
First, by default, Windows creates a complete memory dump under BSODs. At best, this will significantly slow down the reboot. At worst, it will lead to a complete freeze.
Secondly, automatic updates are enabled by default, and there is a risk that one of them will make the work under KVM unstable.
Therefore, after the installation is completed in the very first place (before installing the drivers!), It is recommended to enter the Control Panel => System:
- Automatic update: Disable
- Advanced => Error Report => Disable
- Advanced => Load and Restore => Parameters => System Failure => Write Debug Information => Small Memory Dump (64KB)
TCP / IP settings are optional, but will improve performance a bit, because In a virtual environment, there are some problems that need to be taken into account when transmitting over a physical network.
Description: www.linux-kvm.org/page/WindowsGuestDrivers/kvmnet/registry
Ready REG file: svn1.sytes.net/linuxkvm/tune-guest-tcpip.reg
After that, you can install drivers for the disk (virt-stor) and the network card (virt-net). After installing them, the Red Hat VirtIO SCSI Controller, Red Hat VirtIO SCSI Disk Device and Red Hat VirtIO Ethernet Adapter will appear in the Hardware Manager.
Ballooning
The traditional approach is to immediately allocate a block of RAM of a given size, for example, 512 megabytes, immediately when the virtual machine (VM) starts up. Its disadvantage is in those moments when there is unused space in the VM memory, in other VMs and in the host system it may not be enough.
Memory ballooning is a mechanism for dynamically (a) allocating a host RAM for a VM as needed and (b) returning unused blocks as it is released. Thanks to him, it becomes possible to simultaneously run multiple VMs, the total amount of virtual RAM in which there is more physical RAM in the host system, provided that they do not use the maximum allowed volume all at once. Due to this, the host system memory is distributed between VMs as flexibly as between normal processes.
The creation of virtual resources that exceed the physical in terms of volume is indicated by the terms “overcommit” and “overselling” that are favorite to many hosters.
The operation of the ballooning requires the coordinated operation of two software components:
- MOM (memory overcommitment manager) in the host system, changing the amount of RAM for the VM based on requests from it,
- VMM (Virtual Memory Manager) in a guest OS interacting with MOM through a virtual PCI controller.
MOM in the latest versions of KVM is turned on automatically, the old ones required to enable it using "kvm ... -balloon virtio" on the command line.
The guest device for communicating with the MOM Hardware Controller (devmgmt.msc) will be seen by Windows as an “PCI standard RAM controller” of unknown type. Unlike virt-stor and virt-net, the driver for it will not be offered to be installed automatically. Instead, go to the properties of the device, on the Driver tab, select the update and manually specify the path to balloon.inf on the VirtIO CD ( proof ). After that, the device will be renamed “VirtIO Balloon Driver”.
ACPI
By default, Windows 2003 allows you to turn yourself off in the only way - enter your login and password, select Start => “Shut down”, enter a note, click “OK”. Of course, this approach is unacceptable on a VDS farm. KVM (and QEMU) can emulate ACPI. The “system_powerdown” command is similar to pressing the power button on a physical computer, but Windows will ignore it. It is treated with the following .reg file:
Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\policies\system] "ShutdownWithoutLogon"=dword:00000001 "DisableCAD"=dword:00000001 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows] "ShutdownWarningDialogTimeout"=dword:00000003 He is ready to run: svn1.sytes.net/linuxkvm/win-acpi-kvm.reg
Original source with detailed explanations: umgum.com/acpi-windows2003-shutdown
Caching
If a guest disk image is stored on a VDS farm as a file, guest file caching can be doubled: first, the guest OS caches them when accessing the virtual disk, then the farm OS when accessing the physical one.
In total there are 3 main modes :
- none - the host system does not cache the image file for either read or write
- writeback - write immediately, read is cached
- writethrough - read and write cached
Different versions of qemu / kvm and different operating systems can use different modes by default. For example, Qemu up to version 1.2 uses writethrough, 1.2 switched to writeback, cache = none is selected in Proxmox.
All sources on the Web, without exception, advise not to use writethrough as the slowest. According to a subjective assessment, writeback is optimal for Windows VMs, none is for Linux VMs and FreeBSD VMs.
Network hangs
The only serious problem that the error in KVM unambiguously causes is the hang of the guest network during heavy traffic: bugs.centos.org/view.php?id=5526 (besides the description of the error, there are also important links to other bug trackers).
The recommendations offered by the participants in the discussions (updating qemu-kvm and the kernel, changing the command line parameters, using vhost-net), unfortunately, have not yet been able to solve it.
With each hang, you have to go to the VM console via VNC and reset the network interface, after which the traffic starts walking again normally.
To automate this action in Windows, you can use AutoIt, if you create the file PingFailed_ResetNic.au3 and call it Task Manager every few minutes:
#include «EventLog.au3» Local $PingHost = "192.168.0.1" Local $Interface = "LAN" Ping($PingHost, 250) If @error = 0 Then Exit Local $hEventLog = _EventLog__Open("", "RestartNicOnPingFailure") Local $aEmpty[1] = [0] _EventLog__Report($hEventLog, 2, 0, 1, "", "Restart NIC " & Interface & " on failed ping to " & PingHost, $aEmpty) _EventLog__Close($hEventLog) RunWait("netsh interface set interface " & $Interface & " DISABLED", "", @SW_HIDE) RunWait("netsh interface set interface " & $Interface & " ENABLED", "", @SW_HIDE) Option for CMD.EXE: rickosborne.org/blog/2007/02/stupid-windows-tricks-restart-network-adapter-when-it-hangs
Such a “solution” may not be considered satisfactory everywhere, but in some cases it is enough to reduce the negative effect to an acceptable minimum, allowing one to wait for the release of the correction instead of more drastic measures.
Source: https://habr.com/ru/post/176823/
All Articles