No edit summary |
No edit summary |
||
| Line 14: | Line 14: | ||
=== Network === | === 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. <code>00:16:3e:01:07:30</code>). These will be configured within the guest VM with the virtio driver and connected to the <code>kvm-guests</code> brigde on the | Each guest will be allocated a block of 16 MAC addresses, though only the first in the sequence will typically be used. (e.g. <code>00:16:3e:01:07:30</code>). These will be configured within the guest VM with the virtio driver and connected to the <code>kvm-guests</code> brigde on the Open vSwitch. | ||
Revision as of 02:11, 15 May 2021
A KVM guest instance will be one of the following:
- a Linux virtual server (uv###)
- a Windows virtual desktop (wv9##), typically Windows 10
- a Windows virtual server (ws8##)
1 Linux Virtual Server[edit | edit source]
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.
1.1 Storage[edit | edit source]
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.
1.2 Network[edit | edit source]
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 brigde on the Open vSwitch.
