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 Basic Configuration

In this example, assume that the guest will be named uv051 and that the first MAC address will be 00:16:3e:01:07:30

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/uv051-disk0 is an LV created in the T0 Volume Group (VG) on the KVM host for VM uv051 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 V0uv051. 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

For a Linux Virtual Server, the socat utility will be used to serve up a TCP listener on the KVM host that will connect to the serial console of the guest. The local service socat‑kvm is used to stop and start all these listeners. The TCP port for the listener for a give Guest VM is stored in the file /kvm/socat‑kvm/uv### . To create the file for uv051 specifying the listening port as 7951, use the command echo 7951 > /kvm/socat‑kvm/uv051. After the guest VM is created, use systemctl stop socat‑kvm and systemctl start socat‑kvm to bring up the additional listener.

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 VM & Install OS

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

Connect to the newly created guest via VNC through a tunnel in the current ssh session. For our example creating the Guest VM uv051, the VNC listener will be running on the port 5951 on localhost. Create the tunnel within PuTTY from the Change settings... menu option, navigate to Connection, SSH, Tunnels and then add a local destination forwarded port for source port 5951 and destination localhost:5951. vncviewer can then be used to connect to localhost::5951 to gain direct access to the Guest VM graphics console. Upon connection, the Guest VM instance should have already started the OS installation process.

For CentOS, the Anaconda installer is started from the network install ISO to complete this process. Standard settings for KitsNet installations include:

• Network Configuration: enter the FQDN (i.e.<new‑guest>.lan.kitsnet.us), Apply, then turn on the NIC
• Installation Source: wort/CentOS/8/BaseOS/x86_64/os or wort/Rocky/8/BaseOS/x86_64/os/ or wort/Rocky/9/BaseOS/x86_64/os/
• Software Selection
  • Base Environment: Minimal Install
  • Additional software for Selected Environment: Headless Management, Guest Agent
• Advanced...
  • Create user psmode, specify group manually as 5000 , make the user an administrator (adds to wheel) and add kitsnet_adm (5000) to the group list

Guest OS installation should end with a full shutdown of the guest instance. Use the virsh start uv### command to start the Guest VM and perform a normal boot of the Guest OS.

It will likely be necessary to check the disk lvm partitions to ensure thaty they extend over the entire disk CentOS and Rocky Linux (and presumably Red Hat) will only add enough space to the lvm partitions to provide barely enough space for the LVs defined during installation. Upon boot, use parted to check the partitions and recreate are required, extending the end range to 100% of the disk. It will then be necessary to use pvresize to make the extra space known to lvm and available to the PV and the VG.

4.3 KVM Configuration Updates

[root@wort kvm]# virsh autostart uv033
Domain uv033 marked as autostarted
[root@wort kvm]# virsh desc uv033 --title "cristal (Samba AD DC)"
Domain title updated successfully
[root@wort kvm]# virsh desc uv033 --title "cristal (Samba AD DC)" --config
Domain title updated successfully

4.4 Provisioning KitsNet Environment for the Guest

OS instances, virtual or physical, will be setup in the same fashion. Upon login after the first boot of the instance, configuration of the Guest OS instance should be carried out, according to the OS-specific standard