KVM:guests

A KVM guest instance will be one of the following:

• a Linux virtual server (uv###)
• a Windows virtual desktop (wv9##)
• a Windows virtual server (ws8##)

1 Linux Virtual Server

A Linux guest can run most any Linux OS, though KitsNet natively supports CentOS 7 and CentOS 8 and implements local repo mirrors for these versions. Once RockyLinux 8 is production-ready, support will be added for that distro as well.

2 Windows Virtual Desktop

Windows Virtual Desktop systems may be deployed in the environment with both 32 bit and 64 bit implementations supported. Though versions as old as Windows XP have been supported, Windows 10 should be used in the general case. Installation ISOs are available under the /repo/Windows path on the KVM host. For installation, it will be necessary to attached a second virtual optical device with the virtio-win.iso image mounted to provide access to the virtio drivers for disk and network devices during Windows installation. Windows Virtual Desktop systems may be standalone or domain-joined to the knada.lan.kitsnet.us Active Directory domain. Once the system is built, Microsoft Remote Desktop will be used for access, though this will need to be permissioned for the user within the guest OS.

3 Windows Virtual Server

Windows Virtual Server systems may be deployed in the environment with Windows Server 2008 R2 having been tested. Installation ISOs are available under the /repo/Windows path on the KVM host. For installation, it will be necessary to attached a second virtual optical device with the virtio-win.iso image mounted to provide access to the virtio drivers for disk and network devices during Windows installation. Windows Virtual Server systems may be standalone or domain-joined to the knada.lan.kitsnet.us Active Directory domain. Once the system is built, Microsoft Remote Desktop will be used for access, though this will need to be permissioned for the user within the guest OS.

4 Making a Guest

4.1 Configuration

4.1.1 Disk Storage

Disk storage for guests will usually be implemented using paravirtualized virtio drivers against Logical Volumes (LVs) providing the storage for each virtual disk of the guest. The names of the LVs will reflect the name of the VM and the relative disk number within. For example, /dev/T0/uv031-disk0 is an LV created in the T0 Volume Group (VG) on the KVM host for VM uv031 as its first storage device (disk0) from which it will also boot. This naming scheme permits easy isolation of the LVs for a particular guest in any display. It also allows usage of the diskmon command on the KVM host to quickly identify the source of any IO peaks, down the to guest VM and its internal VG.

Within the VM, volume groups will be created reflective of the physical storage tier and the name of the VM. In the previous example, the resulting VG would be named V0uv031. This naming scheme ensures that al VG names will be unique across all guest VMs. This ensures that it is possible to access guest storage from the KVM host, activate the VGs contained therein and then mount the underlying LVs. This technique is useful for emergency repair as well as backup operations where guest filesystem visibility is required.

4.1.2 Optical Storage

Later....

4.1.3 Graphics Console

A VNC connection will be allocated to facilitate GUI-driven install of the OS in the Guest VM and ongoing access to the graphical console of the Guest VM, though Linux guests will have the primary console set to serial. The VNC connection will be served on the KVM host only from loopback (127.0.0.1), so an ssh tunnel to the KVM host will be required.

4.1.4 Serial Console

kvm-socat

4.1.5 Network

Each guest will be allocated a block of 16 MAC addresses, though only the first in the sequence will typically be used. (e.g. 00:16:3e:01:07:30). These will be configured within the guest VM with the virtio driver and connected to the kvm-guests bridge on the Open vSwitch.

4.2 Create the Guest

Start the creation process with entering the reservation for the new Guest VM on the DHCP server. For systems that will be domain joined, the Hostname part of the reservation should be of the form <new-guest>.knada, while all others will be simply <new-guest>. Once the reservation is entered and saved to the table, it will ne necessary to restart dnsmasq to ensure the reservation is active.

With the DHCP reservation in place, one of the available make scripts can be used.....