Finally migrating from VMplayer to KVM

I have been running VMware, and in particular VMplayer 12.5.x, on my aging Sandybridge (circa 2010) i7-870 desktop for many years and over many interations of Fedora upgrades there have been fights to get it to continue to work. I've been aware of the linux KVM for a while but I've never got around to migrating my Windows7 VM across. Whilst F32 and VMplayer 12.5.x work (with the continued thanks of the out of kernel host modules) it was an idea to finally give this another go.

Originally the Windows 7 VM was cloned from the original Windows 7 installation that was on the aging i7 desktop to run with VMplayer. So I have a working sparse 31GB .vmdk disk image that represents the original 80GB disk.

To migrate to over to KVM I first have to get the disk image into a suitable format:

# convert the image $ qemu-img convert -f vmdk -O qcow2 Win7x64.vmdk Win7x64.qcow2 # ensure the kernel daemon and API running $ systemctl start libvirtd # start the user mgnt tool to create the VM $ virt-manager &

After the new disk image was created, virt-manager was used to create a 4 core and 6GB VM for Windows 7 - and to my surprise the start up of the Windows 7 VM was painless! There were a couple of small admin items was to remove the wmare tools from the running Win 7 guest OS and the installation of virtio drivers (0.1.173-4):

• upgrade network driver
• upgrade graphics driver

by mounting the virtio-win ISO and updating driver from Windows' device manager. Further information.

To enable auto display resolution scaling:

• from select the VM: View -> Scale Display and select: Auto resize VM with window
• from virtaul machine manager: Edit -> Preferences -> Console and Graphical console scale = Always and Resize guest with window = On

From within Windows, set the desired Display resolution (to 1920x1080 for example) and the VM window will automatically scale accordingly.

It's important to note that Windows 7 (and previously WinXP pro) only supports two physical CPUs but unlimited on cores. Therefore its important to set the CPU topology correct, limiting the number of sockets (physical CPUs seen) to two and increasing the number of cores as appropriate.

Now that we have the VM running we need to share data between the linux host and the Win7 guest. Whislt there are some discussions for spice drivers etc theres not a lot of success stories so for now I went with the tried and tested (although painful) samba server on the linux host.

Ensure that samba is installed and we update the firewall (SElinux is not running to remove a bunch of other pain for a single/home box):

$ dnf install samba # verify the zones $ firewall-cmd --get-default-zone public $ firewall-cmd --get-active-zone libvirt interfaces: virbr0 public interfaces: wlp0s20f3 bond0 # notice that 'libvirt' is zone we care about $ firewall-cmd --add-service={samba,samba-client} --permanent --zone=libvirt $ firewall-cmd --reload

Craft the /etc/samba/smb.conf

[global] #log level = 10 workgroup = WORKGROUP # for winxp server min protocol = NT1 lanman auth = yes ntlm auth = yes # allow execution of binaries off the server acl allow execute always = true security = user ; interfaces = 127.0.0.0/8 192.0.0.0/24 virbrg eth0 ; bind interfaces only = yes server role = standalone server obey pam restrictions = yes unix password sync = yes passwd program = /usr/bin/passwd %u passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* . pam password change = yes map to guest = bad user passdb backend = tdbsam usershare allow guests = yes create mask = 0644 directory mask = 0750 [public] comment = Public path = /export/public browseable = yes read only = no guest ok = yes

add final samba admin:

$ testparm $ systemctl enable --now samba nmb # add your user to authenticate and ensure permissions to update/write files to host $ smbpasswd -a ray ...

On the Windows guest side, ensure it can see traffic in its own firewall:

Control Panel Windows Firewall Advanced Settings Inbound Rules Locate "File and Printer Sharing (SMB-In)" right-click and "EnableRule"

And this will be it.

The Windows 7 VM is a safer bet to move than my older WinXP VM primarily because of activation issues - on Windows 7 I've found that the moves to the VM in the past have complained This copy of Windows is not genuine but it NEVER shuts you down. I wasted an old eBay Windows XP pro license creating a Windows XP VM only to find that moving it between linux boxes was enough to request re-activation which would kick you out. Windows 7 on the other hand is still usable but just with the error message in the corner.

Shrinking the qcow2 image

It is possible to reduce the new disk image further although this may be more useful once you have used the VM for a while and the sparse filesystem is no longer sparse: files deleted will not cause the disk image to shrink. To shrink the image within the Windows VM, download sdelete and run as admin on a command prompt. This will zero out the free space to allow for compression:

c:\sdelete.exe -z c:

Once complete, shutdown virtual Windows guest and on the linux host create new disk size optimised disk image:

$ mv Win7x64.qcow2 Win7x64.qcow2_z $ qemu-img convert -f qcow2 -O qcow2 Win7x64.qcow2_z Win7x64.qcow2

For my 80GB virtualised disk, for which 19GB is used, it was sitting at 31GB. Following the resulting zeroed free space the image was about 86GB (as expected since we're not longer sparse as we've zeroed all items on the filesystem) and the converted image was about 25GB.

Finally, whats the point? For me the KVM has been part of the linux kernel since 2.4.x / cira 2007 so its fairly mature and works whereas VMware is a commercial outfit that has already invalidated the software (12.5.x because of old h/w). Technically though, we're left with these reasons for choosing KVM:
Pros:

• KVM part of mainline kernel
• No need for tracking the required kernel modules (via vmware-host-modules) and rebuilding/install on every new kernel upgrade

Cons:

• No easily dedicated folder sharing between Linux host and Windows guest - need to use samba and take its performance hit although there is some work with virtio-fs that should offer much better IO performance but I've struggled to get this to work