KitsNet - User contributions [en]

Linux:Samba AD Factory

2021-05-15T20:29:14Z

2603:7000:9800:4742:1C0E:867B:D1B3:7776: /* Build CentOS 8 / Rocky Linux 8 Base System for Factory */

To use [https://www.samba.org/ Samba] as an Active Directory Domain Controller, Samba must be built from source. While various RPM distros have been made available in the past (and continue to do so today), relying upon these for continued support of these build packages is an operational hazard. Instead, KitsNet has a formalized process to operate a Samba AD "Factory", where [https://www.samba.org/samba/download/ source kits] will be downloaded and built into binaries under the <code>/usr/local/samba</code> directory tree. The resulting binary tree will be packaged into a tarball and subsequently deployed to the Active Directory Domain Controllers for the ''knada.lan.kitsnet.us'' domain.

== Build CentOS 8 / Rocky Linux 8 Base System for Factory ==
Build a basic Linux Virtual Server Guest<ref>[[KVM:guests#Making_a_Guest|KVM:guests#Making_a_Guest]]</ref> with 1.5 GB RAM, 4 vCPU and two disks:

* T0 disk0 10 GB (V0uv000 /tmp 1024 MB, /swap 512 MB, /boot 1 GB, and the rest for /)
* T3 disk1 16 GB (V3uv000 /var 3 GB, /usr/local 13 GB)

When running the Anaconda installer, add to Software Selection, Additional software for Selected Environment: ''Development Tools'' .

KVM:guests

2021-05-15T20:24:12Z

2603:7000:9800:4742:1C0E:867B:D1B3:7776: /* Serial Console */

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##)

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

=== 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 <code>/repo/Windows</code> path on the KVM host. For installation, it will be necessary to attached a second virtual optical device with the <code>virtio-win.iso</code> 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.

=== 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 <code>/repo/Windows</code> path on the KVM host. For installation, it will be necessary to attached a second virtual optical device with the <code>virtio-win.iso</code> 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.

== Making a Guest ==

=== 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''

==== 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, <code>/dev/T0/uv051-disk0</code> is an LV created in the <code>T0</code> Volume Group (VG) on the KVM host for VM <code>uv051</code> as its first storage device (<code>disk0</code>) 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 <code>diskmon</code> 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 <code>V0uv051</code>. 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.

==== Optical Storage ====
Later....

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

==== Serial Console ====
For a Linux Virtual Server, the [https://www.redhat.com/sysadmin/getting-started-socat 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 <code>/kvm/socat‑kvm/uv###</code> . To create the file for ''uv051'' specifying the listening port as ''7951'', use the command <code>echo 7951 > /kvm/socat‑kvm/uv051</code>

Once the parameter file is created, it will be necessary to add entries to the start and stop sections of <code>/etc/rc.d/init.d/socat‑kvm</code> For ''uv051'', these would be <code>__console_start uv051</code> and <code>__console_stop uv051</code> respectively. After the guest VM is created, use <code>systemctl stop socat‑kvm</code> and <code>systemctl start socat‑kvm</code> to bring up the additional listener.

==== 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> bridge on the Open vSwitch.

=== Create the Guest VM & Install OS ===
Start the creation process with entering the reservation for the new Guest VM on the [http://radix.kitsnet.us/cgi-bin/luci/admin/network/dhcp DHCP server]. For systems that will be domain joined, the '''Hostname''' part of the reservation should be of the form <code><''new‑guest''>.knada</code>, while all others will be simply <code><''new‑guest''></code>. Once the reservation is entered and saved to the table, it will ne necessary to [http://radix.kitsnet.us/cgi-bin/luci/admin/system/startup 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 <code>local</code> destination forwarded port for source port <code>5951</code> and destination <code>localhost:5951</code>. '''vncviewer''' can then be used to connect to l<code>ocalhost::5951</code> 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 [https://docs.centos.org/en-US/centos/install-guide/Graphical_Installation-x86/ 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.<code><''new‑guest''>.lan.kitsnet.us</code>), Apply, then turn on the NIC
* Installation Source: <code>wort/CentOS/8/BaseOS/x86_64/os</code>
* Software Selection
** Base Environment: ''Minimal Install''
** Additional software for Selected Environment: ''Headless Management'', ''Guest Agent''
* Advanced...
** Create user <code>psmode</code>, specify group manually as <code>5000</code> , make the user an administrator (adds to <code>wheel</code>) and add <code>kitsnet_adm (5000)</code> to the group list

Guest OS installation should end with a full shutdown of the guest instance. Use the <code>virsh start <''guest''></code> command to start the Guest VM and perform a normal boot of the Guest OS.

=== KVM Configuration Updates ===
autostart

Description

description -config

=== 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<ref>[[KVM:guests:Linux:KitsNet Standard]]</ref>

KVM:guests

2021-05-15T20:24:00Z

2603:7000:9800:4742:1C0E:867B:D1B3:7776: /* Serial Console */

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##)

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

=== 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 <code>/repo/Windows</code> path on the KVM host. For installation, it will be necessary to attached a second virtual optical device with the <code>virtio-win.iso</code> 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.

=== 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 <code>/repo/Windows</code> path on the KVM host. For installation, it will be necessary to attached a second virtual optical device with the <code>virtio-win.iso</code> 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.

== Making a Guest ==

=== 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''

==== 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, <code>/dev/T0/uv051-disk0</code> is an LV created in the <code>T0</code> Volume Group (VG) on the KVM host for VM <code>uv051</code> as its first storage device (<code>disk0</code>) 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 <code>diskmon</code> 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 <code>V0uv051</code>. 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.

==== Optical Storage ====
Later....

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

==== Serial Console ====
For a Linux Virtual Server, the [https://www.redhat.com/sysadmin/getting-started-socat 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 <code>/kvm/socat‑kvm/uv###</code> . To create the file for ''uv051'' specifying the listening port as ''7951'', use the command <code>echo 7951 > /kvm/socat-kvm/uv051</code>

Once the parameter file is created, it will be necessary to add entries to the start and stop sections of <code>/etc/rc.d/init.d/socat‑kvm</code> For ''uv051'', these would be <code>__console_start uv051</code> and <code>__console_stop uv051</code> respectively. After the guest VM is created, use <code>systemctl stop socat‑kvm</code> and <code>systemctl start socat‑kvm</code> to bring up the additional listener.

==== 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> bridge on the Open vSwitch.

=== Create the Guest VM & Install OS ===
Start the creation process with entering the reservation for the new Guest VM on the [http://radix.kitsnet.us/cgi-bin/luci/admin/network/dhcp DHCP server]. For systems that will be domain joined, the '''Hostname''' part of the reservation should be of the form <code><''new‑guest''>.knada</code>, while all others will be simply <code><''new‑guest''></code>. Once the reservation is entered and saved to the table, it will ne necessary to [http://radix.kitsnet.us/cgi-bin/luci/admin/system/startup 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 <code>local</code> destination forwarded port for source port <code>5951</code> and destination <code>localhost:5951</code>. '''vncviewer''' can then be used to connect to l<code>ocalhost::5951</code> 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 [https://docs.centos.org/en-US/centos/install-guide/Graphical_Installation-x86/ 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.<code><''new‑guest''>.lan.kitsnet.us</code>), Apply, then turn on the NIC
* Installation Source: <code>wort/CentOS/8/BaseOS/x86_64/os</code>
* Software Selection
** Base Environment: ''Minimal Install''
** Additional software for Selected Environment: ''Headless Management'', ''Guest Agent''
* Advanced...
** Create user <code>psmode</code>, specify group manually as <code>5000</code> , make the user an administrator (adds to <code>wheel</code>) and add <code>kitsnet_adm (5000)</code> to the group list

Guest OS installation should end with a full shutdown of the guest instance. Use the <code>virsh start <''guest''></code> command to start the Guest VM and perform a normal boot of the Guest OS.

=== KVM Configuration Updates ===
autostart

Description

description -config

=== 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<ref>[[KVM:guests:Linux:KitsNet Standard]]</ref>

KVM:guests

2021-05-15T20:23:18Z

2603:7000:9800:4742:1C0E:867B:D1B3:7776: /* Create the Guest VM & Install OS */

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##)

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

=== 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 <code>/repo/Windows</code> path on the KVM host. For installation, it will be necessary to attached a second virtual optical device with the <code>virtio-win.iso</code> 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.

=== 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 <code>/repo/Windows</code> path on the KVM host. For installation, it will be necessary to attached a second virtual optical device with the <code>virtio-win.iso</code> 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.

== Making a Guest ==

=== 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''

==== 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, <code>/dev/T0/uv051-disk0</code> is an LV created in the <code>T0</code> Volume Group (VG) on the KVM host for VM <code>uv051</code> as its first storage device (<code>disk0</code>) 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 <code>diskmon</code> 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 <code>V0uv051</code>. 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.

==== Optical Storage ====
Later....

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

==== Serial Console ====
For a Linux Virtual Server, the [https://www.redhat.com/sysadmin/getting-started-socat 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 <code>/kvm/socat-kvm/uv###</code> . To create the file for ''uv051'' specifying the listening port as ''7951'', use the command <code>echo 7951 > /kvm/socat-kvm/uv051</code>

Once the parameter file is created, it will be necessary to add entries to the start and stop sections of <code>/etc/rc.d/init.d/socat-kvm</code> For ''uv051'', these would be <code>__console_start uv051</code> and <code>__console_stop uv051</code> respectively. After the guest VM is created, use <code>systemctl stop socat-kvm</code> and <code>systemctl start socat-kvm</code> to bring up the additional listener.

==== 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> bridge on the Open vSwitch.

=== Create the Guest VM & Install OS ===
Start the creation process with entering the reservation for the new Guest VM on the [http://radix.kitsnet.us/cgi-bin/luci/admin/network/dhcp DHCP server]. For systems that will be domain joined, the '''Hostname''' part of the reservation should be of the form <code><''new‑guest''>.knada</code>, while all others will be simply <code><''new‑guest''></code>. Once the reservation is entered and saved to the table, it will ne necessary to [http://radix.kitsnet.us/cgi-bin/luci/admin/system/startup 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 <code>local</code> destination forwarded port for source port <code>5951</code> and destination <code>localhost:5951</code>. '''vncviewer''' can then be used to connect to l<code>ocalhost::5951</code> 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 [https://docs.centos.org/en-US/centos/install-guide/Graphical_Installation-x86/ 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.<code><''new‑guest''>.lan.kitsnet.us</code>), Apply, then turn on the NIC
* Installation Source: <code>wort/CentOS/8/BaseOS/x86_64/os</code>
* Software Selection
** Base Environment: ''Minimal Install''
** Additional software for Selected Environment: ''Headless Management'', ''Guest Agent''
* Advanced...
** Create user <code>psmode</code>, specify group manually as <code>5000</code> , make the user an administrator (adds to <code>wheel</code>) and add <code>kitsnet_adm (5000)</code> to the group list

Guest OS installation should end with a full shutdown of the guest instance. Use the <code>virsh start <''guest''></code> command to start the Guest VM and perform a normal boot of the Guest OS.

=== KVM Configuration Updates ===
autostart

Description

description -config

=== 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<ref>[[KVM:guests:Linux:KitsNet Standard]]</ref>

KVM:guests

2021-05-15T20:22:26Z

2603:7000:9800:4742:1C0E:867B:D1B3:7776: /* Serial Console */

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##)

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

=== 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 <code>/repo/Windows</code> path on the KVM host. For installation, it will be necessary to attached a second virtual optical device with the <code>virtio-win.iso</code> 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.

=== 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 <code>/repo/Windows</code> path on the KVM host. For installation, it will be necessary to attached a second virtual optical device with the <code>virtio-win.iso</code> 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.

== Making a Guest ==

=== 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''

==== 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, <code>/dev/T0/uv051-disk0</code> is an LV created in the <code>T0</code> Volume Group (VG) on the KVM host for VM <code>uv051</code> as its first storage device (<code>disk0</code>) 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 <code>diskmon</code> 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 <code>V0uv051</code>. 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.

==== Optical Storage ====
Later....

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

==== Serial Console ====
For a Linux Virtual Server, the [https://www.redhat.com/sysadmin/getting-started-socat 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 <code>/kvm/socat-kvm/uv###</code> . To create the file for ''uv051'' specifying the listening port as ''7951'', use the command <code>echo 7951 > /kvm/socat-kvm/uv051</code>

Once the parameter file is created, it will be necessary to add entries to the start and stop sections of <code>/etc/rc.d/init.d/socat-kvm</code> For ''uv051'', these would be <code>__console_start uv051</code> and <code>__console_stop uv051</code> respectively. After the guest VM is created, use <code>systemctl stop socat-kvm</code> and <code>systemctl start socat-kvm</code> to bring up the additional listener.

==== 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> bridge on the Open vSwitch.

=== Create the Guest VM & Install OS ===
Start the creation process with entering the reservation for the new Guest VM on the [http://radix.kitsnet.us/cgi-bin/luci/admin/network/dhcp DHCP server]. For systems that will be domain joined, the '''Hostname''' part of the reservation should be of the form <code><''new—guest''>.knada</code>, while all others will be simply <code><''new-guest''></code>. Once the reservation is entered and saved to the table, it will ne necessary to [http://radix.kitsnet.us/cgi-bin/luci/admin/system/startup 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 <code>local</code> destination forwarded port for source port <code>5951</code> and destination <code>localhost:5951</code>. '''vncviewer''' can then be used to connect to l<code>ocalhost::5951</code> 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 [https://docs.centos.org/en-US/centos/install-guide/Graphical_Installation-x86/ 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.<code><''newguest''>.lan.kitsnet.us</code>), Apply, then turn on the NIC
* Installation Source: <code>wort/CentOS/8/BaseOS/x86_64/os</code>
* Software Selection
** Base Environment: ''Minimal Install''
** Additional software for Selected Environment: ''Headless Management'', ''Guest Agent''
* Advanced...
** Create user <code>psmode</code>, specify group manually as <code>5000</code> , make the user an administrator (adds to <code>wheel</code>) and add <code>kitsnet_adm (5000)</code> to the group list

Guest OS installation should end with a full shutdown of the guest instance. Use the <code>virsh start <''guest''></code> command to start the Guest VM and perform a normal boot of the Guest OS.

=== KVM Configuration Updates ===
autostart

Description

description -config

=== 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<ref>[[KVM:guests:Linux:KitsNet Standard]]</ref>

Linux:Samba AD Factory

2021-05-15T19:44:22Z

2603:7000:9800:4742:1C0E:867B:D1B3:7776: /* Build CentOS 8 / Rocky Linux 8 Base System for Factory */

Linux:Samba AD Factory

2021-05-15T19:44:04Z

2603:7000:9800:4742:1C0E:867B:D1B3:7776:

To use [https://www.samba.org/ Samba] as an Active Directory Domain Controller, Samba must be built from source. While various RPM distros have been made available in the past (and continue to do so today), relying upon these for continued support of these build packages is an operational hazard. Instead, KitsNet has a formalized process to operate a Samba AD "Factory", where [https://www.samba.org/samba/download/ source kits] will be downloaded and built into binaries under the <code>/usr/local/samba</code> directory tree. The resulting binary tree will be packaged into a tarball and subsequently deployed to the Active Directory Domain Controllers for the ''knada.lan.kitsnet.us'' domain.

== Build CentOS 8 / Rocky Linux 8 Base System for Factory ==
Build a basic Linux Virtual Server Guest<ref>[[KVM:guests#Making_a_Guest|KVM:guests#Making_a_Guest]]</ref> with 1.5&nbsp;GB RAM, 4 vCPU and two disks:

* T0 disk0 10 GB (V0uv000 /tmp 1024 MB, /swap 512 MB, /boot 1 GB, and the rest for /)
* T3 disk1 16 GB (V3uv000 /var 3 GB, /usr/local 13 GB)

asdf