Creating a virtual machine using Fedora Server Edition disk image
You can install Fedora Server Edition into a virtual machine using the standard installation program for the most flexibility. However, a much quicker approach to bringing up a default Fedora Server instance is to use the pre-built Fedora Server Edition virtual disk image when creating a new virtual machine, and that is what this guide covers.
Fedora Server can be installed in a virtual machine either by using the standard installation program, as described in Installing a Fedora Server virtual machine using Cockpit; or by using the official pre-built Fedora Server virtual disk image, which contains a preinstalled, pre-configured, and ready-to-run operating system.
It is important to note that there are other virtual disk images that might claim to provide a 'Fedora Server'. An example of this is the virt-builder system. However, these images are not the official Fedora Server Edition, but rather deviating concepts around the configuration of a server that is more or less based on the Fedora distribution. While these images have their uses and purposes, many of the Fedora Server administration tools and principles might not be compatible with these images.
Only use the official Fedora Server virtual disk image to create a virtual machine that runs Fedora Server Edition as a supported platform.
What you get
You save time when you create a virtual machine by using the virtual disk image. Instantiating a virtual disk image takes only a few minutes, as opposed to running through the standard installation routines. The workload is significantly lower and correspondingly faster.
The Fedora Server virtual disk image closely matches a standard Fedora Server installation, excluding some hardware-specific configuration. You can configure and administer the guest system independently of the host system, and in everyday practice you should notice no difference from a bare-metal server. The only limit is the virtual hardware resources allocated to the guest, and these can be controlled by the administrator of the host system.
Fedora Server Edition and Fedora Cloud Edition
Unlike the Fedora Cloud Edition image, the Fedora Server virtual disk image is designed to run like any autonomous standalone server, and is optimized for the hypervisor (here QEMU/KVM/libvirt) rather than bare-metal hardware.
Both images 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 from the Fedora Server virtual disk image involves two steps.
-
Provisioning the server VM image
Download the distributed image file and keep it available for creating one or mostly several virtual servers. The appropriate location for this is
/var/lib/libvirt/boot. -
Instantiation of a Server virtual machine
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. Next, import the copied image into Libvirt by using one of the following methods.-
Import by using the CLI with minimal integrated initial configuration
-
Import by using the Cockpit web console with minimal initial configuration
Each of these alternatives then follows a more detailed, mission-specific follow-up customization.
-
Overall, the process is very straightforward and efficient.
Provisioning the server VM image
We assume a complete installation of virtualization support according to the Adding Virtualization Support guide.
-
Download the Fedora Server Edition virtual disk image
If not already done, download and verify the image in the Installation media storage pool. For ARM machines replace 'x86_64' by 'aarch64' in the following example.
$ sudo wget -O /var/lib/libvirt/boot/Fedora-Server-Guest-Generic-44-1.7.x86_64.qcow2 https://download.fedoraproject.org/pub/fedora/linux/releases/44/Server/x86_64/images/Fedora-Server-Guest-Generic-44-1.7.x86_64.qcow2 $ sudo wget -O /var/lib/libvirt/boot/Fedora-Server-44-1.7-x86_64-CHECKSUM https://dl.fedoraproject.org/pub/fedora/linux/releases/44/Server/x86_64/images/Fedora-Server-44-1.7-x86_64-CHECKSUM $ sudo curl -O --output-dir /var/lib/libvirt/boot/ https://fedoraproject.org/fedora.gpg $ sudo gpgv --keyring /var/lib/libvirt/boot/fedora.gpg /var/lib/libvirt/boot/Fedora-Server-44-1.7-x86_64-CHECKSUM $ sudo sh -c ' cd /var/lib/libvirt/boot/ && sha256sum --ignore-missing -c *-CHECKSUM ' Fedora-Server-Guest-Generic-44-1.7.x86_64.qcow2: OK sha256sum: WARNING: 17 lines are improperly formattedYou can safely ignore the warning. The important part of the output here is 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.
$ sudo ls -alZ /var/lib/libvirt/boot/* $ sudo restorecon -R -vF /var/lib/libvirt/boot/* -
Adjust the image file as required
The size of the distribution file optimises efficient deployment and file transfer. The maximum disk size of the server VM image file is 10 GiB. This is not intended for productive operation, but as a starting point for customization.
The minimal recommended size is about 20G. To save your adjustment for further instantiations, and to work with a less complicated file name, create a customized base image.
$ sudo cp /var/lib/libvirt/boot/Fedora-Server-Guest-Generic-44-1.7.x86_64.qcow2 /var/lib/libvirt/boot/Fedora-Server-VM-44-custom.qcow2 $ qemu-img info /var/lib/libvirt/boot/Fedora-Server-VM-44-custom.qcow2 $ sudo qemu-img resize /var/lib/libvirt/boot/Fedora-Server-VM-44-custom.qcow2 40G $ qemu-img info /var/lib/libvirt/boot/Fedora-Server-VM-44-custom.qcow2The example above expands the maximum capacity to 40 GiB. You can resize the disk later, so there is no need to plan generously now. With qcow2, resizing does not change the current image file size, since it grows dynamically as needed, up to the maximum size that is configured.
Instantiation of a server virtual machine
Alternative 1: Import by using CLI
Copy the customized distribution file into the disk image pool, then use virt-install to create the new virtual machine.
In this example, we assume that the VM has two interfaces: one for connecting to the public network and one for connecting to the internal, protected network. Adjust this configuration according to your needs.
You can even install the VM without any interfaces. If you do so, you must use the virsh console ("virsh console <VM_NAME>") to log in and obtain a terminal window.
$ sudo cp /var/lib/libvirt/boot/Fedora-Server-VM-44-custom.qcow2 /var/lib/libvirt/images/${VM_NAME}.qcow2
$ sudo virt-install --name ${VM_NAME} \
--memory 4096 --cpu host-model --vcpus 2 --graphics none \
--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 \
--network bridge=virbr0,model=virtio|
The |
The parameter names are quite descriptive and the values can be adjusted as needed. This example configures two network interfaces. One interface shares the physical public interface in direct mode. The other provides an internal interface using a virtual bridge, as defined during the libvirt installation process. If your public interface resembles a virtual bridge, adjust the command accordingly. Omit any parameters that you do not need. You can find a more detailed explanation of the parameters available in the upstream documentation.
When you run the virt-install command, many messages scroll across the screen. If the network interface does not provide DHCP, you might see a NetworkManager error message. You can safely ignore this message for now.
The installation process ends with a simple, text-based input mask for the first-boot-configuration.
Starting install...
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.
Starting User Login Management...
[ OK ] Started NTP client/server.
[ 21.523663] NET: Registered PF_QIPCRTR protocol family
================================================================================
================================================================================
1) [x] Language settings 2) [x] Time settings
(English (United States)) (Etc/UTC timezone)
3) [x] Network configuration 4) [x] Root password
(Connected: enp2s0, enp1s0) (Root account is disabled)
5) [ ] User creation
(No user will be created)
Please make a selection from the above ['c' to continue, 'q' to quit, 'r' to
refresh]:Specifically, with networks without DHCP you might get a [FAILED] Failed to start NetworkMan…[0m - Network Manager Wait Online. which you safely can ignore for now.
More information on completing this form is covered in Minimal initial configuration.
Alternative 2: Import by using Cockpit
As an alternative to using the CLI, the Cockpit web console provides a graphical interface to perform most of the configuration that you need when setting up the VM.
|
These instructions were written against the Cockpit version shipped with Fedora 44. On other systems, the screens and field names might differ slightly. |
-
Open Cockpit on the host system. The import process expects the virtual disk image at its final location. Therefore, select
Terminalat 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: Import using CLI.
-
Select
Virtual machinesin the left navigation column and thenImport VMin the upper right of the main panel. TheImport a virtual machinedialog opens.
Enter a name for the virtual machine in
Nameand select the disk image copied in the previous step inDisk image. TheOperating systemfield can be set toFedora (unknown)if the current Fedora release is not listed. Set an appropriateMemoryvalue and leaveConnectionon the preselectedSystem.Important! Only if the virtual machine you are creating does not require a network interface, or requires only the internal libvirt
virbr0interface, selectImport and run. The window then shows the process of starting up the virtual machine. -
In all other cases, select
Import and editto set up the correct network connection before the first boot.The details page of the new virtual machine opens. Scroll down to the
Network interfacessection.
-
In the
Network interfacessection, you see one interface withSourceset todefault(the internal libvirt network). This first interface should connect to the public external network, because that keeps the default route easy to manage. So change it to the public interface first. Important: Edit only this interface at this point, to preserve the intended order of the interfaces.Select
Editin the row of the interface to open the settings form.
Set
Interface typetoDirect attachmentandSourceto the external physical interface of the host (for example,enp1s0). KeepModeat the preselectedbridgeand leaveModelandMAC addressunchanged.Finally, select
Saveto return to the details page. -
In the
Network interfacessection, selectAdd network interfacein the upper right.
The form opens with
Interface typeset toVirtual networkandSourcetodefault, which is exactly what is needed for the internal connection. Leave all settings unchanged and selectAdd. -
The
Network interfacessection now lists two interfaces in the correct order: the external one first and the internal one second.
-
Scroll up and select
Startin theConsolepanel. The console window shows the boot process of the virtual machine. SelectExpandat the right top of the console to increase readability.
The console displays the same first-boot configuration menu as in the CLI flow. Continue with the minimal initial configuration.
Minimal initial configuration
You have to use the terminal for this step, whether you performed the instantiation by using CLI or using Cockpit.
-
Complete the first boot configuration
================================================================================ ================================================================================ 1) [x] Language settings 2) [x] Time settings (English (United States)) (Etc/UTC timezone) 3) [x] Network configuration 4) [x] Root password (Connected: enp2s0, enp1s0) (Root account is disabled) 5) [ ] User creation (No user will be created) Please make a selection from the above ['c' to continue, 'q' to quit, 'r' to refresh]:The majority of the input options are already preset with values that correspond exactly to a default installation using the Anaconda Fedora Server Edition installation program. The ROOT account is locked, as is common security practice. The only mandatory remaining task is the creation of a user account granted with administrator privileges.
The selection of a menu item to be edited is achieved by typing the numerical digit of the menu item. For example, a "5" navigates to the item "User creation" and then a "1" navigates to the creation of a new user.
================================================================================ ================================================================================ User creation 1) [x] Create user 2) Full name 3) User name 4) [x] Use password 5) Password 6) [x] Administrator 7) Groups wheel Please make a selection from the above ['c' to continue, 'h' to help, 'q' to quit, 'r' to refresh]:The "[x]" in front of Create user indicates that the user creation process is active. By default, password authentication is enabled for the new user, and administrator privileges are assigned. Complete the required information, including the full name of the user, the user name, and the password fields. A user with Administrator enabled, is automatically added to the
wheelgroup. Do not disable the Administrator account for the initial user.================================================================================ ================================================================================ User creation 1) [x] Create user 2) Full name Peter 3) User name peter 4) [x] Use password 5) Password Password set. 6) [x] Administrator 7) Groups wheel Please make a selection from the above ['c' to continue, 'h' to help, 'q' to quit, 'r' to refresh]:With all user options set, the 'c' returns back to the overview screen.
All non-British users can use the opportunity to adjust the time zone by using option 2 now.
Another "c" continues the entire configuration process. The operation takes some time and then ends in a login prompt.
... ... [ OK ] Finished Initial Setup configuration program. [ OK ] Reached target Preparation for Logins. [ OK ] Started Getty on tty1. [ OK ] Started Serial Getty on ttyS0. [ OK ] Reached target Login Prompts. [ OK ] Reached target Multi-User System. Starting Record Runlevel Change in UTMP... [ OK ] Finished Record Runlevel Change in UTMP. Fedora Linux 44 (Server Edition) Kernel 6.19.10-300.fc44.x86_64 on an x86_64 (ttyS0) Web console: https://localhost:9090/ or https://192.168.158.155:9090/ linux login:In the first lines you may see two SELinux messages similar to:
systemd-gpt-auto-generator[xxxx]: Failed to dissect: Permission denied.You can safely ignore these messages.
The virtual server is up and running now, and ready for login. The initial configuration process is idiosyncratic, but it is simple and straightforward.
-
Login
Login with your credentials you have chosen in the first boot screen described above.
-
Optionally: Adjust locale and non-US keyboard layout
Users of a non-US keyboard layout probably want to customize the keyboard layout first of all. This facilitates any subsequent operation. First, check the current locale configuration
$ localectl System Locale: LANG=en_US.UTF-8 VC Keymap: us X11 Layout: us X11 Model: pc105List available keyboard mappings filtered by your short county code part
$ localectl list-keymaps | grep de- de-T3 de-deadacute de-deadgraveacute de-deadtilde de-mac de-mac_nodeadkeys de-neo de-nodeadkeys ...Determine applicable key mapping and apply it
$ sudo localectl set-keymap de-nodeadkeysThe setting is immediately active.
-
Set hostname
A correct hostname is specifically important for DHCP of the internal network to work properly. A correct time is important for various tasks, specifically synchronization.
-
Check hostname. You need a correct static hostname.
$ hostnamectl -
Set hostname if required:
$ sudo hostnamectl set-hostname <YourFQDN>
-
-
Check time zone and time synchronisation if you missed that previously
-
Check time settings
$ timedatectl -
Correct time zone if necessary:
$ sudo timedatectl set-timezone <ZONE> -
If necessary, activate time synchronisation:
$ sudo timedatectl set-ntp true -
Correct time if necessary:
$ sudo timedatectl set-time <TIME>If you get a warning about RTC time set to local time, follow the instructions to fix it.
-
-
Consolidate the network configuration
-
At first check your interfaces
If you followed the example installation above you should find
$ ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo .... 2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state ... link/ether 52:54:00:3e:0e:f0 brd ff:ff:ff:ff:ff:ff ... 3: enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8000 qdisc fq_codel state ... link/ether 52:54:00:cc:e7:ba brd ff:ff:ff:ff:ff:ff inet 192.168.122.42/24 brd 192.168.122.255 scope global dynamic noprefixroute enp2s0 ...If the external interface does not provide DHCP you will not find an assigned IP address for enp1s0. That is what we would need to fix next.
-
Next let’s check and fix NetworkManager naming
$ nmcli con NAME UUID TYPE DEVICE 'Wired connection 2' 8d971f49-033f-398a-9714-3a4e848178fb ethernet enp2s0 'Wired connection 1' 8d971f49-033f-398a-9714-3a4e848178fb ethernet ---Most likely your interfaces are a named somewhat awkward way. Let’s fix that to make administration of network easier and more comfortable. Do not forget to adjust the naming to your specific installation!
$ sudo nmcli con mod 'Wired connection 1' connection.id enp1s0 $ sudo nmcli con mod 'Wired connection 2' connection.id enp2s0 -
In case DHCP is missing on an interface, configure a static network connection
We take the external interface as an example here.
$ sudo nmcli con mod enp1s0 ipv4.method manual \ ipv4.address "xxx.xxx.xxx.xxx/yy" \ ipv4.gateway "xxx.xxx.xxx.zzz" \ ipv4.dns "xxx.xxx.xxx.vvv" \ ipv6.method manual \ ipv6.addresses xxxx:xxxx:xxxx:xxxx::yyyy/64 \ ipv6.gateway xxxx:xxxx:xxxx:xxxx::zz \ ipv6.dns "xxxx.xxxx.xxxx.xxxx::vvv" \ connection.zone "FedoraServer" $ sudo nmcli con up enp1s0 $ sudo systemctl restart NetworkManager -
The interface enp2s0 for the internal libvirt network might show an IPv6 IP, which we do not use. Therefore, you should disable IPv6 on the internal interface
$ sudo nmcli con mod enp2s0 ipv6.method disabled \ connection.zone "trusted" $ sudo nmcli con up enp2s0 $ sudo systemctl restart NetworkManager -
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
$ 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 100Delete the NAT route to avoid issues because of ambiguous routes by some application software.
$ sudo nmcli con mod enp2s0 ipv4.never-default yes $ sudo nmcli con down enp2s0 $ sudo nmcli con up enp2s0 $ sudo 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
-
-
Adjust firewall setting of the internal interface
The installation program 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).
$ firewall-cmd --get-active-zones $ sudo firewall-cmd --permanent --zone=trusted --change-interface=<internalIF> $ sudo firewall-cmd --reload $ firewall-cmd --get-active-zones -
Optionally adjust default editor
By default
nanois the default system editor in Fedora. Many experienced system administrators prefervim. If you are among the latter, adjust the default editor.$ sudo dnf install vim-default-editor --allowerasing -
F43, F44, F45: Fix the partition table’s LVM partition type
The F44 release assigns a wrong type to one partition. Open the partition editor.
$ sudo cfdisk /dev/vda Disk: /dev/vda Size: 40 GiB, 42949672960 bytes, 83886080 sectors Label: gpt, identifier: BAD551E3-F483-4FB3-BF4C-EF516A914C13 Device Start End Sectors Size Type >> /dev/vda1 2048 6143 4096 2M BIOS boot /dev/vda2 6144 1030143 1024000 500M EFI System /dev/vda3 1030144 5126143 4096000 2G Linux extended boot /dev/vda4 5126144 83886039 78759896 37.6G Linux root (x86-64) ┌──────────────────────────────────────────────────────────────────────────┐ │Partition UUID: 0534CD20-25E4-481A-AD28-E643E5328FDE │ │Partition type: BIOS boot (21686148-6449-6E6F-744E-656564454649) │ └──────────────────────────────────────────────────────────────────────────┘ [ Delete ] [ Resize ] [ Quit ] [ Type ] [ Help ] [ Write ] [ Dump ] Device is currently in use, repartitioning is probably a bad idea. Quit program without writing changesSelect partition vda4, select type, scroll down and assign type "Linux LVM".
-
Finally perform an update and reboot
$ sudo dnf update $ sudo reboot -
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.
# <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 that you can connect to the system over SSH using one of the configured interfaces.
Set up storage
Fedora Server VM guest basically follows the same storage organization principles as a bare-metal installation. The 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 10 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 desired maximum size during the [Provisioning the Server VM image]. Check the output from cfdisk to see whether the last partition has actually been adjusted accordingly. If not, shutdown the virtual machine and adjust the size now.
When qemu-img increases the maximum size of the image file, the last partition is also enlarged accordingly by default. However, the programme can neither adjust the volume group contained within the partition nor the logical volume of the root filesystem.
When installing on bare-metal hardware, there is the option to create a separate partition and volume group for user data. This would also be possible with a virtual disk image. However, as such an image generally requires significantly less storage space and a system partition cannot be installed separately, this is generally not advisable.
So you have to adjust the size of the Volume Group anyway.
Partition vda4 contains the Volume Group (VG).
$ sudo pvresize /dev/vda4
Physical volume "/dev/vda4" changed
1 physical volume(s) resized or updated / 0 physical volume(s) not resized
$ sudo vgdisplay
--- Volume group ---
VG Name systemVG
System ID
Format lvm2
Metadata Areas 1
Metadata Sequence No 3
VG Access read/write
VG Status resizable
...
VG Size 37.55 GiB
PE Size 4.00 MiB
Total PE 9613
Alloc PE / Size 799 / 3.12 GiB
Free PE / Size 8814 / <34.43 GiB
...The Volume Group now provides 37.55 GiB which is the size of the partition.
If you look at the Logical Volumes, there is one volume defined containing the root file system.
$ sudo lvdisplay
--- Logical volume ---
LV Path /dev/systemVG/LVRoot
LV Name LVRoot
VG Name systemVG
...
LV Size 3.12 GiB
Current LE 799
Segments 1
...It is still 3.12 GiB as defined in the distribution file and needs adjustment, too.
Available alternatives
-
Enlarge the Logical Volume to utilise all the free space, and expand the root filesystem accordingly.
This way, there is no separation between system and user data. Whilst this is simple, it is by no means recommended.
-
Enlarge the Logical Volume to utilise a reasonable amount of space and expand the root filesystem accordingly. Create logical volumes for user data or applications as required.
This is the recommended approach. It provides separation of system and user data.
Alternative 2: Enlarge the LV and use the remaining free space for user data
-
Enlarge the LV and the root file system.
A recommended size is 8 - 15G max, depending on the total disk size. As an example, setting the new size is 12 G.
$ sudo lvextend -L 12G /dev/mapper/systemVG-LVRoot Size of logical volume systemVG/LVRoot changed from 3.12 GiB (799 extents) to 12.00 GiB (3072 extents). Logical volume systemVG/LVRoot successfully resized. -
Enlarge the XFS root filesystem to fill the LV
$ sudo xfs_growfs /dev/mapper/systemVG-LVRoot meta-data=/dev/mapper/systemVG-LVRoot isize=512 agcount=4, agsize=204544 blks = sectsz=512 attr=2, projid32bit=1 = crc=1 finobt=1, sparse=1, rmapbt=1 ... data blocks changed from 818176 to 3145728 -
Create an application specific storage space
As an example, one of your service maybe a Jamstack based CMS with decentralized GIT repositories, e.g. Hugo, Jekyll, or alike. You need a place where to store the Git repository with the static HTML files and other data. A
/srv/<MYWEBAPP>would be a perfect place.-
The simple static way
Create a Logical Volume and file system of appropriate size, mount it at
/srv/and create a subdirectory for each application therein.$ sudo lvcreate -L 20G -n srv systemVG Logical volume "srv" created. $ sudo mkfs.xfs -L srv /dev/mapper/systemVG-srv meta-data=/dev/mapper/systemVG-srv isize=512 agcount=4, agsize=655360 blks ... Discarding blocks...Done. $ echo "UUID=$(sudo blkid -s UUID -o value /dev/systemVG/srv) /srv auto defaults 0 0" | sudo tee -a /etc/fstab $ sudo mount -a $ df -h $ sudo mkdir /srv/<MYWEBAPP>This creates a Logical Volume and XFS file system of 20G, mounts t at
/srvand creates a Subdirectory for the web app’s data. Add additional subdirectories for each application. -
The elaborate way using thin provisioning
In the case of thin provisioning, you create a dynamic logical volume which initially occupies only the space immediately required and then grows as needed up to a specified maximum size. This dynamic volume is mounted in a corresponding subdirectory within /srv/ on the root filesystem. Each application thus receives its own logical volume, which simplifies many maintenance processes and makes more effective use of the physically available space. All other features that make logical volumes so attractive from a maintenance and data security perspective are retained.
The dynamic logical volumes reside in a
thin pool, which technically must have a fixed size. The sum of the respective maximum sizes of the dynamic LVs it contains may nominally exceed the size of the pool, but in practice can only be utilised up to the specified physical size. The size of the thin pool can be expanded at any time, provided the physical or virtual disk allows it.Thin provisioning takes place in three steps.
-
Creating a thin provisioning pool
In the example we specify a size of 20 G, which nearly occupies the available space. A following `lvs`checks if the result meets the expectation.
$ sudo lvcreate -L 20G --thin systemVG/thinpool Thin pool volume with chunk size 64.00 KiB can address at most <15.88 TiB of data. Logical volume "thinpool" created. $ sudo lvs LV VG Attr LSize Pool Origin ... LVRoot systemVG -wi-ao---- 12.00g thinpool systemVG twi-a-tz-- 20.00g ... -
Creating a thinly provisioned Logical Volume
In this example we create a Logical Volume of 4G at maximum. The system will create it with an much lower initial size.
$ sudo lvcreate -V 4G -T systemVG/thinpool -n <MYWEBAPP> Logical volume "<MYWEBAPP>" created. $ sudo lvs LV VG Attr LSize Pool ... LVRoot systemVG -wi-ao---- 12.00g <MYWEBAPP> systemVG Vwi-a-tz-- 4.00g thinpool ... thinpool systemVG twi-aotz-- 20.00g ...Repeat this step for every application you have to provide with storage.
-
Mounting the file system at the intended location
$ sudo mkdir /srv/<MYWEBAPP> $ echo "UUID=$(sudo blkid -s UUID -o value /dev/systemVG/<MYWEBAPP>) /srv/<MYWEBAPP> auto defaults 0 0" | sudo tee -a /etc/fstab $ sudo mount -a $ df -hRepeat this step for every application you have to provide with storage.
-
Instead of using the command line, you can also switch to Cockpit and perform each of these operations in a graphical User Interface.
-
Creating additional storage resources
Another way so separate system and user data is to create a separate virtual data disk.
You can use either CLI or Cockpit for this step.
Using CLI
-
On the host system, create a new virtual disk in /var/lib/libvirt/images
$ sudo qemu-img create -f qcow2 /var/lib/libvirt/images/${VM_NAME}-usr.qcow2 20G Formatting '/var/lib/libvirt/images/vm01-test-usr.qcow2', fmt=qcow2 cluster_size=65536 extended_l2=off compression_type=zlib size=21474836480 lazy_refcounts=off refcount_bits=16 $ qemu-img info /var/lib/libvirt/images/${VM_NAME}-usr.qcow2 file format: qcow2 virtual size: 20 GiB (21474836480 bytes) disk size: 196 KiB cluster_size: 65536 Format specific information: compat: 1.1 compression type: zlib lazy refcounts: false refcount bits: 16 corrupt: false extended l2: false -
Continue on the host and add the disk to the virtual machine. Use the first available disk name. The system disk is vda, so the next available disk name is
vdb. If you are unsure check in the virtual machine, e.g. usinglsblk.$ sudo virsh attach-disk ${VM_NAME} /var/lib/libvirt/images/${VM_NAME}-usr.qcow2 vdb --cache default --persistent --targetbus=virtio --subdriver qcow2 Disk attached successfullyThe command needs the absolute path to the image file as noted. Otherwise it will fail. The disk is available immediately.
If you want to modify something, detach the file first.
$ sudo virsh detach-disk ${VM_NAME} vdb --persistent Disk detached successfully -
On the virtual machine, use
cfdiskto partition the disk according to your requirements. The example creates one partition spanning the entire disk capacity.First,
cfdiskdisplays a list for selecting the partitioning type. Select GPT.$ sudo cfdisk /dev/vdb Disk: /dev/vdb Size: 192.5 KiB, 197120 bytes, 385 sectors Label: gpt, identifier: 2842C26B-A2F1-4946-9D89-AB8832E5FCEC Device Start End Sectors Size Type >> Free space 34 351 318 159K [ New ] [ Quit ] [ Help ] [ Write ] [ Dump ] Create new partition from free space -
Create a Physical Volume (PV) in the new partition (adjust the device accordingly!)
$ sudo pvcreate /dev/vdb1 Physical volume "/dev/vdb1" successfully created. -
Create a Volume Group (VG) in the new Physical Volume (adjust the device accordingly!)
$ sudo vgcreate usrvg /dev/vdb1
Later, use usrvg to create LVs for user data as needed.
Using Cockpit
-
Open Cockpit on your host system, select Virtual Machines in the navigation column, and then select the machine to which you want to add a disk. Scroll down until you see the disk section. Finally, select Add disk on the right side of the subtitle bar.
Most of the input fields are suitably preconfigured. Enter a (file) name for the disk image. Use a consistent naming scheme to facilitate long-term system maintenance. Specify the intended maximum size of the disk and decide on "Always attach". It is best to leave the other properties untouched.
Select Add to complete the task.
-
Open Cockpit on the virtual machine you added the device to and select Storage. Cockpit assigns automatically the next disk identifier, /dev/vdb in case of Server VM.
-
Select the new disk and create a partition table and file system as needed.
Follow-up customization
It is advisable to review all the tasks in the general Postinstallation Customizations guide for virtual machines as well.
Want to help? Learn how to contribute to Fedora Docs ›