Managing virtual machines with Cockpit

Cockpit is powerful but not (yet) perfect. The current version does not provide a graphical tool for that purpose. The system administrator still has to rely on CLI tools like qemu-img or the virt-* utilities of guestsfs-tools. Fortunately, we just have to use the CLI tool to increase the virtual disk image while the VM is stopped. Afterwards, we can start the VM again and use the VM’s Cockpit to reconfigure the storage.

As an example, use vm2 Cockpit to display the current configuration of storage. Open http://vm2:9090 (again, adjust the address as appropriate) in your browser, log in, and select Storage from the left navigation column.

In the Filesystems section of the central content area [1] there are 2 file systems: root of 11 GiB and boot of 1 GiB. Additional information is in the right column. The Devices section indicates a Volume group of 11 GiB [2]. This implies that the root file system completely fills this Volume group. The Drives section lists a virtual disk of 12 GiB [3]. This implies that this disk is completely filled with the two file systems.

After shutting down vm2, we can increase the virtual disk by 20 GiB to a total of 32 GiB in the hosts Cockpit terminal.

As the info shows, the virtual disk size is now 32 GiB. The file still occupies only 2.01 GiB in the directory, due to the qcow2 dynamic file format.

This is due to the qcow2 file format, which dynamically occupies the necessary space as needed. Therefore, the size of the extension should be chosen quite generously to potentially save the work of a later re-extension. In the case of multiple virtual machines, the sum of their size can also exceed the real available space. This is not a problem as long as not all virtual machines at the same time grow to a much greater extent than planned. However, flexibility is gained in the case of disproportionate growth of some single virtual machines.

After starting vm2 again the Storage page now shows unsurprisingly a disk of 32 GiB, but nothing else changed. So the disk has now 20 GiB unallocated space.

Fedora Servers default storage setup is based on the concept of segmenting storage to facilitate system administration, prevent spillover of errors, and others. For details, see the Fedora Server Installation Guide. Therefore, if you need additional space for an application or service, e.g. web service, you would create a separate Logical volume in Fedora Server following that rationale.

You have three options now:

We will continue with alternative 2 here. It is just as committed to the Fedora Server rationale as alternative 1, if not even stricter. It is with Cockpit the more comfortable variant and in the end implements the same actions, i.e. creating a Logical volume with file system and mounting it at a fitting position in the directory tree. And alternative 3 is conceptually the worst of all.

On the vm2 Storage page select the 32 Gib virtual disk and in the new page that opens click on the "Create partition" button right below the /dev/vda2 partition [1].

You only have to change the type to "No filesystem" [2] and create the partition. It takes some time before a third partition is displayed in the list.

Go back to the Storage page. At the top of the right column, activate the menu icon next to Devices and select "Create volume group".

In the form that opens, enter a name for the Volume group, here in analogy to fedora_fedora of the system area fedora_user, select the newly created partition /dev/vda3, and create the Volume group. The form closes and on the Storage page you find a new device, the fedora_user Volume group of 20.0 GiB.

As already mentioned, in compliance with the Fedora Server storage concept, a data area separate from system data should contain the service and user data. One FSH-compatible way is to mount the /srv directory in a separate Logical volume and store therein the respective data for all services. Another way is to mount a well-known dedicated application directory into its own Logical volume. For example, in Fedora Server, PostgreSQL stores all its data into /var/lib/pgsql or Apache httpd in /var/www. These directories are each mounted in their own Logical volumes, preferably before the software is installed.

As an example we install httpd data into a separate logical volume. Just in case the software is already installed, stop httpd and move the data temporarily out of the way. We will restore them later. The directory /var/www should be empty.

The Storage page of the virtual machine (vm2) displays the Devices section in the top right column, and within the volume group fedora_user that we configured earlier. Clicking fedora_user opens the volume group configuration page. Below the box with details of the volume group is a list of the existing logical volumes of this volume group.It provides a link "Create new logical volume" to the right of the title, which opens a configuration form.

Replace the preset name by a descriptive term, here e.g. webservice, and choose a suitable size. Due to the dynamic space allocation of the qcow2 format you may choose the size definitely a bit generous. However, a later extension with Cockpit is very easy to perform.

With Purpose the form also offers the option to create a pool for "thinly provisioned volumes", which in turn accommodates logical volumes allocating space dynamically. In case of a VM this is usually not as helpful as on physical machines, because the qcow2 disk image files already provide for a kind of thin provisioning. But your mileage may vary.

After creating the Logical volume you find an entry in the list "Logical volumes". Expand the line using the triangle icon. You will find a Format Button. The associated form allows you to create and mount a file system in one pass.

You just have to provide a (descriptive) name and the mount point. After formatting you will find the volume group mounted and ready to use.

Cockpit handled all the various configuration steps involved on its own. This saves the system administrator quite a bit of effort. It even includes creating the mount directory if it does not already exist. At the end of the day, Cockpit makes it very easy for the system administrator to implement the elaborate storage concept of Fedora Server.

If you moved files out of the way at the beginning, you can restore them now. To be on the safe side, restore the SELinux labels.

Now is the time to install the appropriate programs. Software provided by Fedora distribution as rpm installs into the appropriate system directories via dnf tool. External software should install in either /opt or /usr/local to keep it separated from distribution files to prevent any potential mutual interference. In accordance with the storage rationale, you should also create a separate logical volume and mount it under /opt. An example of this would be Wildfly application server, which stores program, configuration and possibly data in a common place.

Expanding the virtual (system) disk is not the only way to provide additional storage, nor is it necessarily the best way. In the case of virtual disk images, creating a dedicated virtual disk instead of creating Logical volumes is a solid, often better alternative. It adds more flexibility. For example, in case of the "cold standby" VM mentioned above, the system administrator can assign the (virtual) disk with the entire current dataset to the other VM in less than a minute.

Cockpit supports the creation of additional virtual disks (but unfortunately not to modify an existing one). On the virtual machine details page in the section Disks you find an Add Disk button. It opens a form to fill in.

In the example above we create a 30gb disk for Web service. Add creates a disk image in /var/lib/libvirt/images and adds it to the Cockpit VM details page. You may check in the terminal window using lsblk. It shows a disk vdb without any partition so far.

The Host Cockpit simply creates a new (virtual) hard disk and "plugs" it into the virtual machine. Configuration and setup of the hard disk occurs within the VM. Their Cockpit can perform that very easily. Open a new tab in your browser, open Cockpit of the VM and select Storage over there.

On the right side you see the newly created disk listed as part of the (virtual hardware) equipment of the VM. You can work on this disk like on any other. A click opens a corresponding dialog form.

The system administrator can create a partition table and one or more partitions, can create a Volume group and Logical Volumes the same way as described in the previous section. It is also possible to set up and mount a file system directly without a partition table. Cockpit enables and supports all these options comfortably and efficiently.

You may have configured a virtual machine with just a public interface in order to provide some public service. According to the general recommendations it uses mac-vlan as an efficient connection type. In the virtual machines Cockpit GUI it shows up as "type: direct" and "Source: enp1s0", the host’s physical interface [1].

After some time you may need to access a service provided by the host, e.g. a database service. Because the public interface uses mac-vlan, a direct communication between host and virtual machine is not possible (due to technical limitations of that type). Additionally, you may want to protect that communication and its data from the public. The solution is to add an interface to the virtual machine that connects to the libvirt internal virtual network, named default and using virbr0.

With Cockpit it is just a click on the "Add network interface" link right of the section title [2] and to fill in a simple form.

In case of an internal interface leave everything as suggested, but just activate "Always attach" to make it automatically available after reboot. Use the button "Add" to create the interface.

The interface shows up below the public interface. And inside the virtual machine a "ip a" shows and additional connection "enp7s0". Cockpit sets everything up on its own, no further involvement of the system administrator required.

You may have configured a virtual machine with just an internal interface, which works perfectly as (the only) interface enp1s0. Now you need public access instead. The easiest way is to edit the interface definition in Cockpit.

In the network section of the VMs detail page there is just one interface with 3 buttons: Delete, Unplug, and Edit. The latter opens a interface properties form.

The form shows the definition of the current internal network. Just modify the Interface type from "Virtual network" to "Direct attachement" and Source from "default" to "enp1s0", the host physical interface. Save your selection and reboot. Assuming DHCP works, the virtual machine has a perfectly working connection to the public network, including name resolution and default firewall configuration. Otherwise you have to define a static network configuration.

Even if you need a public interface in addition to the existing internal interface you may prefer to edit the existing interface and later add a new internal interface. That way you follow the common practice of always setting up the public interface as the "first" one, i.e. enp1s0 or eth0.

As an example, the virtual maschine is equipped with two interfaces, a public (enp1s0) and an internal (enp7s0).

Probably you don’t want a public interface but that machine well protected from the public network. So you delete the public interface. A simple click on Delete will remove that interface from the virtual machine (after confirmation). If you check the network configuration inside the machine an nmcli device show lists only one device as attached to the still existing connection. And ip a lists just lo and enp7s0.

An nmcli conn show still lists the connection enp1s0, but without an attached device. The reason is that it was the first interface explicitly set up during installation. Therefore it was persisted in /etc/NetworkManager/system-connected and the file is still there (allthough without any device configuration options). Cockpit does not delete a configuration file.