Merge branch 'virtimginst-upd'

modules/ROOT/pages/services/filesharing-nfs-installation.adoc.bak

@@ -0,0 +1,443 @@
+= File sharing with NFS – Installation
+Peter Boy (pboy);Emmanuel Seyman (eseyman); Jason Beard (cooltshirtguy); Otto Liljalaakso; Jocelyn Gould (korora)
+//:page-authors: {author}
+:revnumber: F43
+:revdate: 2025-10-30
+//:page-aliases: installation-an-introduction.adoc
+
+
+[abstract]
+// ------
+NFS, the Network File System, is a mature protocol designed to share files between Unix-type systems over TCP/IP networks. Fedora Server Edition installs by default the kernel space NFS server, but without configuration and activation. This article describes its configuration and activation.
+
+// ------
+
+The objective of this guide is how to setup __NFS Server__ on a Fedora Server Edition. For information on how to setup the client part, consult your OS's documentation.
+
+NFS is a Network service in Linux used to share the files and directories of the Server to users (clients) on the network. It allows clients to _mount_ a remote directory or complete filesystem over a network and interact with it much like local storage is accessed. It is the same principle as Map Drive in Windows Systems. One of it most used benefits is to store and access data on central location.
+
+The NFS Protocol was first introduced by Sun Microsystem in 1984. The protocol has evolved from its origins. Over the years, new versions have been released, adding new features. Currently, NFS v4.2 is the current version.  Perhaps most practically significant is the optional user identification as well as a virtual ROOT.
+
+NFS protocol is not encrypted by default, and unlike Samba, unless you activate the optional feature it does not provide user authentication. Access to the server is restricted by the clients’ IP addresses or hostnames.
+
+The kernel space NFS server features high performance and is therefore selected as default. Fedora Server also supports user space NFS server. However, this is not the subject of this article.
+
+
+== Preparation
+
+There are three packages which provide basic support for kernel space NFS:
+
+nfs-utils::
+is the main package and provides a daemon for the kernel NFS server and related tools. It also contains the _showmount_ program to query the mount daemon on a remote host for available ressources, eg listing the clients which are mounted on that host. It also contains the mount.nfs and umount.nfs programs.
+libnfsidmap::
+NFSv4 User and Group ID Mapping Library that handles mapping between names and ids for NFSv4.
+sssd-nfs-idmap::
+ SSSD plug-in provides a way for rpc.idmapd to call SSSD to map UIDs/GIDs to names and vice versa. It can be also used for mapping principal (user) name to IDs(UID or GID) or to obtain groups which user are member of.
+
+Ensure that these packages are really installed.
+[source,]
+----
+[…]$ rpm -qa | grep nfs
+libnfsidmap-2.8.4-0.fc43
+sssd-nfs-idmap-2.11.1-4.fc43
+nfs-utils-2.8.4-0.fc43
+----
+
+If a package missing, then a system administrator can simply reinstall it.
+
+
+=== Organizing storage
+
+In principle, NFS can share any directory on the server. However, it makes sense to concentrate at least generally shared files in a central location instead of scattering everything around.
+
+Furthermore, it is a best practice is to use a global NFS root directory and bind mount those directories which are holding specific data at specific locations to the share mount point.
+
+In accordance to the Filesystem Hierarchie Standard (FSH), using a /srv/nfs4 directory as the NFS root is a good choice.
+
+Following Fedora Server storage rationale, a system administrator will create a logical volume and mount it to either `/srv` to create a Logical Volume as a pool for various services, or `/srv/nfs` to create a Logical Volume, probably thin provisioned, for each service.  In case of systematic extensive  utilization, a static LVM volume of fixed size is advisable. For occasional usage, a thin provisioned logical LVM volume might be the better choice.
+
+In this guide we will demontrate the latter and create a thin provisioned LV for each service in /srv.
+
+1. *Create a nfs export directory in /srv*
++
+[source,]
+----
+[…]$ sudo mkdir /srv/nfs
+----
++
+The created directory is by default readable for everyone, but not writable.
+
+2. *Create a user and group nfs*
++
+As already stated, nfs does not provide user authentication. A common way is to either use the same UID/GID for a given user on all devices on the network or to map every client to user nobody and make the export files read- and writable for everybody, i.e. for any user of the system. The former is difficult to achieve without a central logon instance, and the latter is at best inconvenient from a security point of view. So we use a pseudo user without a home directory and without a login shell, who owns all exported files and directories by default.
++
+[source,]
+----
+[…]$ sudo adduser -c 'nfs pseudo user' -M  -r  -s /sbin/nologin  nfs
+----
+
+3. *Create and mount the required Logical Volumes*
++
+The easiest way is to use Cockpit with its storage module. Select on the right side the root Volume Group and select "Add logical volume" in the new window.
++
+image::services/nfs-server-inst-001.png[Create logical volume]
++
+Fill in the form as needed. It is useful to name the LV to reflect the content or directory you want to store. Select "Pool for thinly provisioned volumes" and choose an appropriate size to accommodate all the data you plan to store.
++
+In the list of logical volumes that is then displayed, the line with the newly created LV contains the option "Create thin volume". It opens a new form to create a LV to store data. We will use it for nfs exports.
++
+image::services/nfs-server-inst-005.png[Create thin volume]
++
+Fill in the form appropriately. Keep in mind that you are specifying the maximum value for the size of the volume. The system starts with a much smaller initial value and expands it as needed.
++
+After the creation of the volume the list of logical volumes contains a new entry for the logical Volume just created with an option "Format". It opens a new form.
++
+image::services/nfs-server-inst-009.png[Format the new logical volume]
++
+Again, fill in the form and you are done.
++
+For hardcore system administrators with mouse allergy, the whole thing via CLI.
++
+[source,]
+----
+[…]# lvcreate -L 40G -T fedora/srv -V 30G -T fedora/srv -n nfs
+[…]# lvs
+[…]# mkfs.xfs /dev/fedora/nfs
+[…]# mkdir -p /srv/nfs
+[…]# vim /etc/fstab
+...
+/dev/mapper/fedora-root     /                  xfs   defaults    0 0
+/dev/mapper/fedora-nfs      /srv/nfs           xfs   defaults    0 0
+...
+----
++
+Finallly mount the created filesystem.
++
+[source,]
+----
+[…]# mount -a
+----
+
+4. *Create and configure the directories to share*
++
+In a typical use case you may create a directory 'common' to widely share data and a directory 'project', in which a team member shares data located in the home directory with the team.
++
+[source,]
+----
+[…]# sudo mkdir -p /srv/nfs/{common,project}
+[…]# sudo chown  -R  nfs:nfs  /srv/nfs/*
+[…]# sudo mount --bind /home/USER/PROJECT  /srv/nfs/project
+----
++
+To make the bind mount(s) permanent, add the following entries to the /etc/fstab file:
++
+[source,]
+----
+[…]# vi /etc/fstab
+/home/USER/PROJECT  /srv/nfs/PROJECT   none   bind   0   0
+----
+
+
+== Optional server configuration
+
+NFS server configuration uses 3 files
+
+* /etc/nfs.conf
+* /etc/nfsmount.conf
+* /etc/idmapd.conf
+
+The commented out lines describe the default built in configuration.
+
+1. Configure the NFS basic directory
++
+[source,]
+----
+[…]$ sudo vi /etc/nfs.conf
+/home/USER/PROJECT  /srv/nfs/PROJECT   none   bind   0   0
+----
+
+== Activation
+
+1. *Firewall configuration*
++
+NFS uses port 2049 which is blocked in a Fedora standard installation  by defaut.
++
+[source,]
+----
+[…]# firewall-cmd --permanent --add-service=nfs
+[…]# firewall-cmd --reload
+----
+
+2. *Start NFS enabling autostart at boot time*
++
+[source,]
+----
+[…]# systemctl enable nfs-server --now
+[…]# systemctl status nfs-server
+----
++
+This starts the NFS server only, but not the NFS client. Therefore, the server can not mount file ressources provided by another server. If required, additionally execute at first _`systemctl enable nfs-client.target --now`_. For additional details you may look at _`man 7  nfs.systemd`_.
+
+3. Check availabe NFS capabilities
++
+Fedora enables versions 3 and 4.x, version 2 is disabled. The latter is pretty old now. Every machine should provide at least version 3.
++
+[source,]
+----
+[…]# cat /proc/fs/nfsd/versions
+-2 +3 +4 +4.1 +4.2
+----
++
+So the NFS server supports versions 3 and all version 4 capabilities.
+
+
+
+
+== File resource configuration
+
+//====
+//**Possible/intended topics**
+
+//* Create configuration file
+//* (optionally) configure password authentification (NFS 4)
+//* (optionally) deactivate rpcbind
+//+
+//Set 'vers3=n' in the '[nfsd]' section of
+// /etc/nfs.conf, mask the RPC services, and restart NFS:
+//+
+//systemctl mask --now rpc-statd.service rpcbind.service rpcbind.socket
+//systemctl restart nfs-server
+//+
+//(see  https://access.redhat.com/documentation/zh-cn/red_hat_enterprise_linux/8/html/deploying_different_types_of_servers/configuring-an-nfsv4-only-server_exporting-nfs-shares[Configuring an NFSv4-only server] )
+//
+//See for some additional ideas:
+//
+//* https://access.redhat.com/documentation/zh-cn/red_hat_enterprise_linux/8/html/deploying_different_types_of_servers/exporting-nfs-shares_deploying-different-types-of-servers[Exporting NFS shares]
+//* or https://www.tecmint.com/install-nfs-server-on-centos-8/[How to Set Up NFS Server and Client on CentOS 8]
+//
+//====
+
+NFS provides 2 options to configure which directores and files to share
+
+/etc/exports::
+the "traditional" grand all-in-one configuration file
+/etc/exports.d::
+the new way, a directory to collect a set of specific configuration files, which is read file by file at startup. These files must have the extension *.exports. The format is the same as the grand configuration file.
+
+You can use both options in parallel with the grand configuration file read in first. We will use the modern form only.
+
+=== Configuration by example
+
+Example 1::
+Export the directory /srv/nfs/common with everyone, i.e. every network device and every user, can access with Read/Write and Synchronize access
++
+[source,]
+----
+[…]$ sudo vi /etc/exports.d/common.exports
+<i(nsert)>
+/srv/nfs/common *(rw,sync)
+----
+
+Example 2::
+Export the directory /srv/nfs/common with everyone, i.e. every network device and every user, can access with Read/Write and Synchronize access
++
+[source,]
+----
+[…]$ sudo vi /etc/exports.d/common.exports
+<i(nsert)>
+/srv/nfs/common *(rw,sync)
+----
+
+Example 3::
+Export the directory /srv/nfs/common with everyone, i.e. every network device and every user, can access with Read/Write and Synchronize access
++
+[source,]
+----
+[…]$ sudo vi /etc/exports.d/common.exports
+<i(nsert)>
+/srv/nfs/common *(rw,sync)
+----
+
+Example 4::
+Export the directory /srv/nfs/common with everyone, i.e. every network device and every user, can access with Read/Write and Synchronize access
++
+[source,]
+----
+[…]$ sudo vi /etc/exports.d/common.exports
+<i(nsert)>
+/srv/nfs/common *(rw,sync)
+----
+
+Example 6::
+Export the directory /srv/nfs/projects with all users of a specific network device with Read/Write and Synchronize access
++
+[source,]
+----
+[…]$ sudo vi /etc/exports.d/projects.exports
+<i(nsert)>
+/srv/nfs/common *(rw,sync)
+----
+
+==== Connection options
+
+Each default for every exported file system must be explicitly overridden. For example, if the rw option is not specified, then the exported file system is shared as read-only.
+
+For basic options of exports
+Option 	Description
+
+rw/wo::
+Allow both read and write requests / only read requests on a NFS volume.
+sync/async::
+Reply to requests only after the changes have been committed to stable storage (Default) / allow the NFS server to violate the NFS protocol and reply to requests before any changes made by that request have been committed to stable storage.
+secure/insecure::
+Require that requests originate on an Internet port less than IPPORT_RESERVED (1024). (Default) /  accepts all ports. using the insecure option allows clients such as Mac OS X to connect on ports above 1024. This option is not otherwise "insecure".
+wdelay/no_wdelay:: 	Delay committing a write request to disc slightly if it suspects that another related write request may be in progress or may arrive soon. (Default)
+ 	This option has no effect if async is also set. The NFS server will normally delay committing a write request to disc slightly if it suspects that another related write request may be in progress or may arrive soon. This allows multiple write requests to be committed to disc with the one operation which can improve performance. If an NFS server received mainly small unrelated requests, this behaviour could actually reduce performance, so no_wdelay is available to turn it off.
+subtree_check/no_subtree_check::
+This option enables subtree checking. (Default)
+ 	This option disables subtree checking, which has mild security implications, but can improve reliability in some circumstances.
+root_squash/no_root_squash::
+Map requests from uid/gid 0 to the anonymous uid/gid. Note that this does not apply to any other uids or gids that might be equally sensitive, such as user bin or group staff.
+ 	Turn off root squashing. This option is mainly useful for disk-less clients.
+all_squash/no_all_squash::
+Map all uids and gids to the anonymous user. Useful for NFS exported public FTP directories, news spool directories, etc.
+ 	Turn off all squashing. (Default)
+anonuid=UID::
+These options explicitly set the uid and gid of the anonymous account. This option is primarily useful for PC/NFS clients, where you might want all requests appear to be from one user. As an example, consider the export entry for /home/joe in the example section below, which maps all requests to uid 150.
+anongid=GID::
+Read above (anonuid=UID)
+
+Setting the crossmnt option on the main psuedo mountpoint has the same effect as setting nohide on the sub-exports: It allows the client to map the sub-exports within the psuedo filesystem. These two options are mutually exclusive.
+
+=== Administration
+
+When the nfs service starts, the /usr/sbin/exportfs command launches and reads this file, passes control to rpc.mountd (if NFSv2 or NFSv3) for the actual mounting process, then to rpc.nfsd where the file systems are then available to remote users.
+
+When issued manually, the /usr/sbin/exportfs command allows the root user to selectively export or unexport directories without restarting the NFS service. When given the proper options, the /usr/sbin/exportfs command writes the exported file systems to /var/lib/nfs/xtab. Since rpc.mountd refers to the xtab file when deciding access privileges to a file system, changes to the list of exported file systems take effect immediately.
+
+The following is a list of commonly used options available for /usr/sbin/exportfs:
+
+
+
+    -r — Causes all directories listed in /etc/exports to be exported by constructing a new export list in /etc/lib/nfs/xtab. This option effectively refreshes the export list with any changes that have been made to /etc/exports.
+
+    -a — Causes all directories to be exported or unexported, depending on what other options are passed to /usr/sbin/exportfs. If no other options are specified, /usr/sbin/exportfs exports all file systems specified in /etc/exports.
+
+    -o file-systems — Specifies directories to be exported that are not listed in /etc/exports. Replace file-systems with additional file systems to be exported. These file systems must be formatted in the same way they are specified in /etc/exports. Refer to Section 18.7, “The /etc/exports Configuration File” for more information on /etc/exports syntax. This option is often used to test an exported file system before adding it permanently to the list of file systems to be exported.
+
+    -i — Ignores /etc/exports; only options given from the command line are used to define exported file systems.
+
+    -u — Unexports all shared directories. The command /usr/sbin/exportfs -ua suspends NFS file sharing while keeping all NFS daemons up. To re-enable NFS sharing, type exportfs -r.
+
+    -v — Verbose operation, where the file systems being exported or unexported are displayed in greater detail when the exportfs command is executed.
+
+If no options are passed to the /usr/sbin/exportfs command, it displays a list of currently exported file systems.
+
+
+==== Using exportfs with NFSv4
+
+The exportfs command is used in maintaining the NFS table of exported file systems. When typed in a terminal with no arguments, the exportfs command shows all the exported directories.
+
+Since NFSv4 no longer utilizes the rpc.mountd protocol as was used in NFSv2 and NFSv3, the mounting of file systems has changed.
+
+An NFSv4 client now has the ability to see all of the exports served by the NFSv4 server as a single file system, called the NFSv4 pseudo-file system. On Red Hat Enterprise Linux, the pseudo-file system is identified as a single, real file system, identified at export with the fsid=0 option.
+
+For example, the following commands could be executed on an NFSv4 server:
+
+[source,]
+----
+mkdir /exports
+mkdir /exports/opt
+mkdir /exports/etc
+mount --bind /usr/local/opt /exports/opt
+mount --bind /usr/local/etc /exports/etc
+exportfs -o fsid=0,insecure,no_subtree_check gss/krb5p:/exports
+exportfs -o rw,nohide,insecure,no_subtree_check gss/krb5p:/exports/opt
+exportfs -o rw,nohide,insecure,no_subtree_check gss/krb5p:/exports/etc
+----
+
+In this example, clients are provided with multiple file systems to mount, by using the --bind option which creates unbreakeable links.
+
+Because of the pseudo-file systems feature, NFS version 2, 3 and 4 export configurations are not always compatible. For example, given the following directory tree:
+
+[source,]
+----
+/home
+/home/sam
+/home/john
+/home/joe
+----
+
+and the export:
+
+[source,]
+----
+/home *(rw,fsid=0,sync)
+----
+
+Using NFS version 2,3 and 4 the following would work:
+
+[source,]
+----
+mount server:/home /mnt/home
+ls /mnt/home/joe
+----
+
+Using v4 the following would work:
+
+[source,]
+----
+mount -t nfs4 server:/ /mnt/home
+ls /mnt/home/joe
+----
+
+The difference being "server:/home" and "server:/". To make the exports configurations compatible for all version, one needs to export (read only) the root filesystem with an fsid=0. The fsid=0 signals the NFS server that this export is the root.
+
+[source,]
+----
+/ *(ro,fsid=0)
+/home *(rw,sync,nohide)
+----
+
+Now with these exports, both "mount server:/home /mnt/home" and "mount -t nfs server:/home /mnt/home" will work as expected.
+
+
+== Testing the configuration
+
+On client side:
+[source,]
+----
+[…]# showmount -e 192.168.12.200
+----
+
+On client side, try to mount an exported subdirectory:
+[source,]
+----
+[…]# mount 192.168.1.200:/nfsfileshare /mnt/nfsfileshare
+----
+
+Display the active  mounts
+[source,]
+----
+[…]# mount | grep nfs
+sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw,relatime)
+nfsd on /proc/fs/nfsd type nfsd (rw,relatime)
+192.168.12.5:/nfsfileshare on /mnt/nfsfileshare type nfs4 (rw,relatime,vers=4.1,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=192.168.12.7,local_lock=none,addr=192.168.12.5)
+----
+
+Check if the NFS mount is writable
+[source,]
+----
+[…]# touch /mnt/nfsfileshare/test
+----
+
+
+
+== Adding user identification and encryption (NFS 4)
+
+TBD
+
+== Further reading
+
+* Upstream documentation: http://linux-nfs.org/wiki/index.php/Main_Page
+* Linux manual page: https://man7.org/linux/man-pages/man5/exports.5.html

modules/ROOT/pages/virtualization/vm-install-diskimg-fedoraserver.adoc

@@ -1,8 +1,8 @@
 = Creating a virtual machine using Fedora Server Edition disk image
-Peter Boy
+Peter Boy, Jocelyn Gould
 :page-authors: {author}
-:revnumber: F39-F41
-:revdate: 2024-11-01
+:revnumber: F39-F43
+:revdate: 2025-12-04
 // :revremark: a new beginning
 :page-aliases: pages/virtualization-vm-install-diskimg-fedoraserver.adoc
 
@@ -17,7 +17,7 @@ There are 2 ways to create a Fedora Server in a virtual machine. System administ
 xref:virtualization/vm-install-fedoraserver-cockpit.adoc[Installing a Fedora Server virtual machine using Cockpit].
 In this process, a number of properties and functionalities can be adapted to local requirements. Or they can download a Fedora Server virtual disk image containing an already preinstalled, pre-configured and ready-to-run operating system and mount it in a virtual machine.
 
-There exist a multitude of virtual disk images that claim to provide a server based on the Fedora distribution. An example of this is the xref:virtualization/vm-install-diskimg-virtbuilder.adoc[virt-builder] system. However, it is not a Fedora Server, but its own, deviating concept for the configuration of a server. And accordingly, e.g., the Fedora Server administration tools and principles may not fit. System administrators can also create their own disk images using tools such as _xref::tutorials/imagefactory.adoc[Image Factory]_ or __Image Builder__.
+There exist a multitude of virtual disk images that claim to provide a server based on the Fedora distribution. An example of this is the xref:virtualization/vm-install-diskimg-virtbuilder.adoc[virt-builder] system. However, it is not a Fedora Server, but its own, deviating concept for the configuration of a server. And accordingly, e.g., the Fedora Server administration tools and principles may not fit. 
 
 
 == What you get
@@ -26,9 +26,11 @@ To begin with, you gain time. Instantiating a virtual disk image takes only a fe
 
 Fedora Server KVM image resembles all features and properties of a Fedora Server as close as possible, except for  directly hardware-related measures, of course. In general, the system administrator of a virtual server (guest system) can perform configuration and administration largely independently and autonomously from the system administrator of the host system. Ideally, they should not notice any difference in everyday practice. As the system administrator of the host is limited by the available hardware resources, the administrator of the guest system is just limited only by the virtual hardware resources.
 
+=== Fedora Server Edition and Fedora Cloud Edition
+
 Unlike a cloud image, Fedora Server VM is designed to run like any self-sustaining server, albeit optimized for a generic hypervisor (here QEMU/KVM/libvirt) rather than bare-metal hardware. 
 
-_Fedora Cloud Image_ and _Fedora Server Image_ have in common that they adhere to the build process and control of the distribution.
+Both have in common that they adhere to the build process and control of the distribution. However, they follow different principles of data administration and organization, and are subject to different workflows.
 
 == How it works
 The creation of a virtual machine image involves two steps.
@@ -52,20 +54,23 @@ Overall, the process is very straightforward and efficient.
 
 We assume a complete installation of virtualization support according to the xref:virtualization/installation.adoc[Adding Virtualization Support] guide.
 
-1. If not already done, *download the Fedora Server Edition* virtual disk image into the _Installation media_ storage pool and verify the image. This involves the following steps.
+1. If not already done, *download the Fedora Server Edition* virtual disk image into the _Installation media_ storage pool and verify the image. This involves the following steps on x86_64 hardware. For ARM machines replace 'x86_64' by 'aarcb64' in the following example.
 +
 [source,]
 ----
 […]$ sudo -i
 […]# cd /var/lib/libvirt/boot
-[…]# 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 
+[…]# wget https://download.fedoraproject.org/pub/fedora/linux/releases/43/Server/x86_64/images/Fedora-Server-Guest-Generic-43-1.6.x86_64.qcow2  
+[…]# wget https://download.fedoraproject.org/pub/fedora/linux/releases/43/Server/x86_64/iso/Fedora-Server-43-1.6-x86_64-CHECKSUM 
 […]# curl -O https://fedoraproject.org/fedora.gpg
-[…]# gpgv --keyring ./fedora.gpg Fedora-Server-41-1.4-x86_64-CHECKSUM 
+[…]# gpgv --keyring ./fedora.gpg Fedora-Server-43-1.6-x86_64-CHECKSUM 
 […]# sh -c ' cd /var/lib/libvirt/boot/  &&  sha256sum --ignore-missing -c *-CHECKSUM ' 
-Fedora-Server-KVM-41-1.4.x86_64.qcow2: OK
+Fedora-Server-Guest-Generic-43-1.6.x86_64.qcow2: OK 
+sha256sum: WARNING: 17 lines are improperly formatted
 ----
 +
+You can savely ignore the warning. Important is just the OK status of the image.
++
 If you copy or move files directly from elsewhere, you should check the correct SELinux label and correct it if necessary.
 + 
 [source,]
@@ -74,33 +79,34 @@ If you copy or move files directly from elsewhere, you should check the correct
 […]# restorecon -R -vF /var/lib/libvirt/boot/* 
 ----
 
-2. *Adjust the image file* to your needs. The maximum disk size of the server VM image file is 7GB, of which about 6GB in the root file system is free. This is not intended for pro­ductive operation, but as a starting point for customization. The minimal recommended size is  about 20G. To save these adjustment steps for further instantiations, create a customized base image. Copy the disk image to an intermediate file and adjust the maximum disk size.
+2. *Adjust the image file* to your needs. The maximum disk size of the server VM image file is 10 GiB, of which about 6GB in the root file system is free. This is not intended for productive operation, but as a starting point for customization. The minimal recommended size is  about 20G. To save these adjustment steps for further instantiations, create a customized base image. Copy the disk image to an intermediate file and adjust the maximum disk size.
 +
 [source,]
 ----
 […]# cd /var/lib/libvirt/boot 
-[…]# 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
+[…]# cp Fedora-Server-Guest-Generic-43-1.6.x86_64.qcow2 Fedora-Server-43-custom.qcow2
+[…]# qemu-img info   /var/lib/libvirt/boot/Fedora-Server-43-custom.qcow2
+[…]# qemu-img resize /var/lib/libvirt/boot/Fedora-Server-43-custom.qcow2 40G
+[…]# qemu-img info   /var/lib/libvirt/boot/Fedora-Server-43-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.
-+
-If you intend to create multiple VMs with similar structure, it may be useful to customize the customised file in detail. See section _Import via CLI and elaborated initial configuration_ further down.
+
+//+  ToDo: Write a excursus on image customization
+//If you intend to create multiple VMs with similar structure, it may be useful to customize the customised file in detail. See section _Import via CLI and elaborated initial configuration_ further down.
 
 == Instantiation of a Server virtual machine
 
 === Alternative 1: Import efficiently via CLI  
 
-Copy the customized distribution file into the disk image pool and use virt-install to instantiate the new virtual machine. In the example, we assume that the VM has 2 interfaces, one for connecting to the public network and another for connecting to the internal protected network. 
+Copy the customized distribution file into the disk image pool and use virt-install to instantiate the new virtual machine. In the example, we assume that the VM has 2 interfaces, one for connecting to the public network and another for connecting to the internal protected network. Adjust this to your needs. You could even install the VM without any interface. In this case, you must use the virsh console ('virsh console <VM_NAME>) to log in and obtain a terminal window.
 
 [source,]
 ----
-[…]# cp /var/lib/libvirt/boot/Fedora-Server-KVM-41-custom.qcow2  /var/lib/libvirt/images/{VM_NAME}.qcow2
+[…]# cp /var/lib/libvirt/boot/Fedora-Server-43-custom.qcow2  /var/lib/libvirt/images/{VM_NAME}.qcow2
 […]# virt-install  --name <VM_NAME> \
      --memory 4096  --cpu host --vcpus 2 --graphics none \
-     --os-variant fedora41 \
+     --os-variant fedora-unknown \
      --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 +114,7 @@ Copy the customized distribution file into the disk image pool and use virt-inst
 ----
 [IMPORTANT]
 ====
-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.
+If a message "Unknown OS name 'fedora43'" 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.
 
@@ -117,8 +123,8 @@ A lot of messages then scroll across the screen. If the network interface doesn'
 [source,]
 ----
 Starting install...
-Running text console command: virsh --connect qemu:///system console vm1-test
-Connected to domain 'vm1-test'
+Running text console command: virsh --connect qemu:///system console rbox03
+Connected to domain 'rbox03'
 Escape character is ^] (Ctrl + ])
 ...
 [  OK  ] Reached target User and Group Name Lookups.
@@ -147,34 +153,57 @@ 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 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, select terminal at the bottom of the left navigation column and copy the prepared customized disk image into the disk image pool, as you did in alternative 1 (CLI import).
 +
-image::virtualization/diskimg-fedoraserver-01.png[Cockpit initial terminal]
+.Cockpit initial terminal
+image::virtualization/diskimg-fedoraserver-01.png[]
 
 2. Select "__Virtual Machines__" in the left navigation column and select "__Import VM__" at the right top of the central window area.
 +
-image::virtualization/diskimg-fedoraserver-02.png[Cockpit import screen]
+.Cockpit import screen
+image::virtualization/diskimg-fedoraserver-02.png[]
 +
 Fill in the input fields as appropriate and leave "__Connection__" on "__System__" as preselected.
 
 
 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.  
++
+.Cockpit new virtual machine overview screen
+image::virtualization/diskimg-fedoraserver-03.png[]
 
-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.
+4. Scroll down to get to the network and devices section 
 +
-image::virtualization/diskimg-fedoraserver-03.png[Network re-configuration]
+.Network and devices screen
+image::virtualization/diskimg-fedoraserver-04.png[]
 +
-Modify Interface type to Direct attachment and Source to the physical host external interface. Leave Model and MAC address unchanged! Save brings you back to the Overview screen.
+In the network section, 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. Therefore, we start with changing this interface into the public one. Important: To keep the intended order of interfaces, do nothing else at tis point as to edit this interface!  
 
-5. In the row "Network interfaces" select Add network interface on the right side.
+5. Select the _Edit_ button to adjust the network connection setup.
 +
-image::virtualization/diskimg-fedoraserver-04.png[Add network interface]
+.Network re-configuration screen
+image::virtualization/diskimg-fedoraserver-05.png[]
 +
-In the window that opens, the internal virtual network is already selected and correctly configured. Select Add to add the interface.
+Modify Interface type to Direct attachment and Source to the physical host external interface (enp1s0) and select bridge mode. Leave Model and MAC address unchanged! 
++
+Finally, select __Save__. You will return to Network and devices.
 
-6. Scroll up and select _Run_ In the console window you will see the creation and startup of the virtual machine. Expand the console window. 
+6. In the row "Network interfaces" select _Add network interface_ on the right side.
 +
-image::virtualization/diskimg-fedoraserver-05.png[Final User Configuration]
+.Add network interface
+image::virtualization/diskimg-fedoraserver-06.png[]
++
+The form opening already has Network Type selected and correctly configured.  Leave all settings unchanged and close the form with the Add button.
+
+7. The network and devices part of the screen now contains 2 network interfaces in the correct order. 
++
+.Two network interfaces configured
+image::virtualization/diskimg-fedoraserver-07.png[]
++
+
+8. Scroll up and select _Start_ in the middle of the central window. In the console window you will see the creation and startup of the virtual machine. Expand the console window. 
++
+.Minimal initial configuration form
+image::virtualization/diskimg-fedoraserver-08.png[]
 +
 Finally, the screen displays the same configuration menu as with a CLI setup. Continue with the minimal initial configuration.
 
@@ -270,8 +299,8 @@ 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 41 (Server Edition)
-Kernel 6.11.4-301.fc41.x86_64 on an x86_64 (ttyS0)
+Fedora Linux 43 (Server Edition)
+Kernel 6.17.1-300.fc43.x86_64 on an x86_64 (ttyS0)
 
 Web console: https://localhost:9090/ or https://192.168.158.155:9090/
 
@@ -292,7 +321,8 @@ Users of a non-US keyboard layout probably want to customize the keyboard layout
 […]# localectl
 System Locale: LANG=en_US.UTF-8
     VC Keymap: us
-   X11 Layout: us
+   X11 Layout: us 
+   X11 Model: pc105
 ----
 + 
 List available keyboard mappings filtered by your short county code part
@@ -363,6 +393,8 @@ d. Correct time if necessary:
 ----
 […]# timedatectl set-time  <TIME>
 ----
++
+If you get a warning about RTC time set to local time, follow the instructions to fix it. 
 
 5. *Consolidate the network configuration*
 +
@@ -486,14 +518,24 @@ By default nano is the default system editor in Fedora. Many experienced system
 […]# dnf update
 […]# reboot
 ----
+9. *Close the virsh console mode*
++
+You were automatically in virsh's console mode until now. Exit this mode and you will be back on the host system.
++
+[source,]
+----
+[…]# <ctrl>]
+Domain creation completed.
+[…]# 
+----
 
 If you opted for Cockpit to instantiate the VM you may use Cockpits graphical interface for the last 4 steps.
 
-Anyway, you should now test to connect via ssh to the system, if it provides an external interface.
+Anyway, you should now test to connect via ssh to the system using the usual way, i.e. using one of the configured interfaces.
 
 == Set up storage
 
-Fedora Server KVM follows the same storage organization principles as the base installation. The xref:installation/index.adoc#Planning_ahead[Fedora Server Installation Guide] explains the principles and the available choices. You have to make the same choice here.
+Fedora Server KVM guest follows the same storage organization principles as the base installation. The xref:installation/index.adoc#Planning_ahead[Fedora Server Installation Guide] explains the principles and the available choices. You have to make the same choice here.
 
 The distributed disk image features a disk size of about 7 gb. This is not intended as a default value to use but as a starting value for adaptation to the specific installation requirement. You have probably already adjusted the total desired size at the xref:#instantiation_of_a_server_virtual_machine[begin of installation]. If not, shutdown the virtual machine and adjust the size now. As already noted, you need not to be too sparing in the choice. You can easiy enlarge the maximum size later. And thanks to the qcow2 format, it allocates just the space that is actually needed and doesn't waste resources. On the other hand, there is also no reason to be overly generous.