selrahal/user-documentation
1
0
Fork 0
forked from server/user-documentation
Code Pull requests Activity

Updated KVM Server text to F41

Browse source
This commit is contained in:
Peter Boy 2024-11-01 16:00:23 +01:00
commit d8546d5e77
1 changed files with 53 additions and 30 deletions
Download patch file Download diff file Expand all files Collapse all files

83
docs/modules/ROOT/pages/virtualization/vm-install-diskimg-fedoraserver.adoc
View file

@ -1,8 +1,8 @@
= Creating a virtual machine using Fedora Server Edition disk image
Peter Boy
:page-authors: {author}
:revnumber: F39
:revdate: 2024-01-17
:revnumber: F39-F41
:revdate: 2024-11-01
// :revremark: a new beginning
:page-aliases: pages/virtualization-vm-install-diskimg-fedoraserver.adoc
@ -40,7 +40,7 @@ Basically you will download the distributed image file and keep it available for
2. *Instantiation of a Server virtual machine*
+
To do this, first create a copy of the distribution image in the pool of disk images (`/var/lib/libvirt/images`) with the name of the VM to be instantiated. This image is then imported into Libvirt using one of the following methods.
+
a. _Import via CLI using minimal integrated initial configuration_
b. _Import via Cockpit with comfortable minimal initial configuration_
+
@ -58,12 +58,12 @@ We assume a complete installation of virtualization support according to the xre
----
[…]$ sudo -i
[…]# cd /var/lib/libvirt/boot
[…]# wget https://download.fedoraproject.org/pub/fedora/linux/releases/39/Server/x86_64/images/Fedora-Server-KVM-39-1.5.x86_64.qcow2
[…]# wget https://download.fedoraproject.org/pub/fedora/linux/releases/39/Server/x86_64/images/Fedora-Server-39-1.5-x86_64-CHECKSUM
[…]# wget https://download.fedoraproject.org/pub/fedora/linux/releases/41/Server/x86_64/images/Fedora-Server-KVM-41-1.4.x86_64.qcow2
[…]# wget https://download.fedoraproject.org/pub/fedora/linux/releases/41/Server/x86_64/images/Fedora-Server-41-1.4-x86_64-CHECKSUM
[…]# curl -O https://fedoraproject.org/fedora.gpg
[…]# gpgv --keyring ./fedora.gpg *-CHECKSUM
[…]# pgv --keyring ./fedora.gpg Fedora-Server-41-1.4-x86_64-CHECKSUM
[…]# sh -c ' cd /var/lib/libvirt/boot/ && sha256sum --ignore-missing -c *-CHECKSUM '
Fedora-Server-KVM-37-20221002.n.0.x86_64.qcow2: OK
Fedora-Server-KVM-41-1.4.x86_64.qcow2: OK
----
+
If you copy or move files directly from elsewhere, you should check the correct SELinux label and correct it if necessary.
@ -79,10 +79,10 @@ If you copy or move files directly from elsewhere, you should check the correct
[source,]
----
[…]# cd /var/lib/libvirt/boot
[…]# cp Fedora-Server-KVM-39-1.5.x86_64.qcow2 Fedora-Server-KVM-39-custom.qcow2
[…]# qemu-img info /var/lib/libvirt/boot/Fedora-Server-KVM-39-custom.qcow2
[…]# qemu-img resize /var/lib/libvirt/boot/Fedora-Server-KVM-39-custom.qcow2 40G
[…]# qemu-img info /var/lib/libvirt/boot/Fedora-Server-KVM-39-custom.qcow2
[…]# cp Fedora-Server-KVM-41-1.4.x86_64.qcow2 Fedora-Server-KVM-41-custom.qcow2
[…]# qemu-img info /var/lib/libvirt/boot/Fedora-Server-KVM-41-custom.qcow2
[…]# qemu-img resize /var/lib/libvirt/boot/Fedora-Server-KVM-41-custom.qcow2 40G
[…]# qemu-img info /var/lib/libvirt/boot/Fedora-Server-KVM-41-custom.qcow2
----
+
The example above expands the maximal capacity to 40 GiB. You can resize the virtual disk later, too. Therefore, there is no reason to plan too generously in terms of size now. Due to the qcow2 format resizing does not affect the current image file size. It is dynamically adjusted as needed up to the maximum specified.
@ -97,10 +97,10 @@ Copy the customized distribution file into the disk image pool and use virt-inst
[source,]
----
[…]# cp /var/lib/libvirt/boot/Fedora-Server-KVM-39-custom.qcow2 /var/lib/libvirt/images/{VM_NAME}.qcow2
[…]# cp /var/lib/libvirt/boot/Fedora-Server-KVM-41-custom.qcow2 /var/lib/libvirt/images/{VM_NAME}.qcow2
[…]# virt-install --name <VM_NAME> \
--memory 4096 --cpu host --vcpus 2 --graphics none \
--os-variant fedora39 \
--os-variant fedora41 \
--import \
--disk /var/lib/libvirt/images/<VM_NAME>.qcow2,format=qcow2,bus=virtio \
--network type=direct,source=enp1s0,source_mode=bridge,model=virtio \
@ -108,7 +108,7 @@ Copy the customized distribution file into the disk image pool and use virt-inst
----
[IMPORTANT]
====
If a message "Unknown OS name 'fedora37'" appears, the list has not yet been updated in virt-install. You can then use "fedora-unknown" without any problems.
If a message "Unknown OS name 'fedora41'" appears, the list has not yet been updated in virt-install. You can then use "fedora-unknown" without any problems.
====
The parameters are quite descriptive and are to be adjusted accordingly. You will find a more detailed explanation in the appendix.
@ -147,7 +147,7 @@ We continue with this form in the step after describing the Cockpit way of insta
=== Alternative 2: Import comfortably via Cockpit
1. Open Cockpit on your host system. The import subroutine expects the virtual hard disk at the final location. Therefore, copy the prepared customized disk image into the disk image pool, as you did in alternative 1 (CLI import). Select _Terminal_ in the left navigation column to perform this step.
1. Open Cockpit on your __host system__. The import expects the virtual hard disk at the final location. Therefore, copy the prepared customized disk image into the disk image pool, as you did in alternative 1 (CLI import). Select _Terminal_ in the left navigation column to perform this step.
+
image::virtualization/diskimg-fedoraserver-01.png[Cockpit initial terminal]
@ -160,7 +160,7 @@ Fill in the input fields as appropriate and leave "__Connection__" on "__System_
3. If the VM to be created should only have one network interface connected to the internal libvirt bridge (virbr0), select __Import and run__. In __all other cases__, select _Import and edit_ to set up the correct network connection before the first boot.
4. Adjust the network connection setup. The screen changes and the VM overview page. Scroll down to __Network interfaces__. You see one Interface with Source default, i.e. virbr0. In order to easily manager the default route, this interface - the first one created - should connect to the public external network. Select _Edit_ to modify the Source.
4. Adjust the network connection setup. The screen changes and the VM overview page. Scroll down to __Network interfaces__. You see one Interface with Source default, i.e. virbr0. In order to easily manage the default route, this interface - the first one created - should connect to the public external network. Select _Edit_ to modify the Source.
+
image::virtualization/diskimg-fedoraserver-03.png[Network re-configuration]
+
@ -270,12 +270,12 @@ Another "c" continues with the execution of the entire configuration process. Th
Starting Record Runlevel Change in UTMP...
[ OK ] Finished Record Runlevel Change in UTMP.
Fedora Linux 35 (Server Edition)
Kernel 5.16.18-200.fc35.x86_64 on an x86_64 (ttyS0)
Fedora Linux 41 (Server Edition)
Kernel 6.11.4-301.fc41.x86_64 on an x86_64 (ttyS0)
Web console: https://fedora:9090/ or https://192.168.158.155:9090/
Web console: https://localhost:9090/ or https://192.168.158.155:9090/
fedora login:
linux login:
----
+
In the first lines you may get 2 SELinux messages alike "systemd-gpt-auto-generator[xxxx]: Failed to dissect: Permission denied". You can savely ignore those messages.
@ -435,6 +435,30 @@ d. The interface enp2s0 for the internal libvirt network may show an IPv6 IP, wh
[…]# systemctl restart NetworkManager
----
e. Check the default routes if you have 2 interfaces, one with an external public connection, one with the internal network, which uses NAT by default. So you have 2 parallel connection paths to access the public network and will find something like
+
[source,]
----
[…]# ip r
default via 192.168.158.1 dev enp1s0 proto dhcp src 192.168.158.160 metric 100
default via 192.168.122.1 dev enp2s0 proto dhcp src 192.168.122.107 metric 101
192.168.122.0/24 dev enp2s0 proto kernel scope link src 192.168.122.107 metric 101
192.168.158.0/24 dev enp1s0 proto kernel scope link src 192.168.158.160 metric 100
----
+
Delete the NAT route to avoid issues because of ambigous routes by some application software.
+
[source,]
----
[…]# nmcli con mod enp2s0 ipv4.never-default yes
[…]# nmcli con down enp2s0
[…]# nmcli con up enp2s0
[…]# systemctl reload NetworkManager
[…]# ip r
default via 192.168.158.1 dev enp1s0 proto dhcp src 192.168.158.160 metric 100
192.168.122.0/24 dev enp2s0 proto kernel scope link src 192.168.122.107 metric 101
192.168.158.0/24 dev enp1s0 proto kernel scope link src 192.168.158.160 metric 100
----
6. *Adjust firewall setting of the internal interface*
+
The installer assigns all interfaces to the _FedoraServer_ zone, which limits access to ssh (and Cockpit). For the internal, protected network a broader accessibility may be appropriate, depending on the use case. If appropriate, modify the configuration (check alternative zone and select a suitable one).
@ -500,6 +524,9 @@ Login to the virtual machine and use the cfdisk utility to display the space all
Quit program without writing changes
----
As you see, on the disk there is unused space, not associated to any partition. Quit cfdisk for now.
Partition vda3 contains a Volume Group (VG).
[source,]
----
@ -517,6 +544,9 @@ Partition vda3 contains a Volume Group (VG).
VG UUID ybQrEj-xSeB-SWxw-4BMM-VXAG-3re7-2rt3xr
----
As you see, the complete space is occupied by a Logical Volume (LV).
Check the logical volume
[source,]
----
[…]# lvdisplay
@ -534,10 +564,12 @@ As you see, the complete space is occupied by a Logical Volume (LV).
Block device 253:0
----
As you see, the Logical Volume is of the same size as the Volume Group, about 6 GiB.
=== Available alternatives
1. Enlarge the LVM partition to file all of the free space and enlarge the root file system alike. In this way, there is no separation of system and user data. This is convenient, but in no way recommendable.
2. Enlarge the LVM partition to file all of the free space and enlarge the root file system to a reasonable value between 10 and 15 gb, depending on the intended total size of the disc. In the free space, the administrator later creates logical volumes for user data as needed. This is the recommended way.
2. Enlarge the LVM partition to file all of the free space and enlarge the root file system to a reasonable value between 10 and 15 gb, depending on the intended total size of the disc. The remaining space in the Volume Group remains free for now. Later, the administrator creates logical volumes for user data or applications as needed. This is the recommended way.
3. Enlarge the existing VG and the root file system to a reasonable size. Create a new VG in the remaining region, which later accommodates LVs for user data. This pushes the separation even further.
4. Enlarge the distributed virtual disk to a reasonable size to accommodate the root file system only and create one or more separate virtual disk(s) to accommodate user data.
@ -764,12 +796,3 @@ image::virtualization/diskimg-fedoraserver-35.png[VM disk partitioning]
It is advisable to review all the tasks in the general xref:installation/postinstallation-tasks.adoc[post-installation guide] for virtual machines as well.
== Import via CLI and elaborated initial configuration
The procedure described so far works well and efficiently when only one virtual machine is to be set up, or even with multiple machines that differ.
To add an elaborated initial configuration is specifically useful, if multiple similar instantiations are on the agenda. This works very similar, but uses guestfs-tool's _virt-customize_ before the virt-install step, either by means of command line parameters or a configuration file.
Details TBD