KDE Plasma 5.25 in Arch

After the recent release of KDE Plasma 5.25, this version landed a few days ago in Arch-based distros like EndeavourOS (the one I’m writing from).

Although I’m mostly a GNOME user, I also have a few distributions installed where I’m using KDE Plasma.

The new features that impressed me most are related to eye candies 🙂

First, the “Present Windows” effect now looks the same as the new “Overview” effect. If we compare the “Present Windows” effect in the previous version (5.24):

with the new one:

we can see a significant improvement: in the earlier versions, the windows not selected were too dark, making it hard to distinguish them. This behavior relates to an old bug (10 years old): https://bugs.kde.org/show_bug.cgi?id=303438. This bug has been fixed by rewriting this effect “to use the same modern, maintainable backend technology found in the Overview effect.”

I use this effect a lot (I also configured the “Super” key to use this effect, simulating what happens in Gnome for its “Activities” view), and I use the filter to filter the open windows quickly. So I appreciate this usability change a lot!

One detail I do not like in this new version of “Present Windows” is that the filter textbox remembers the entered text. Thus, the next time you use it, the presented windows are already filtered according to the previously entered text. I’m not sure I like this.

The other cool thing introduced is the automatic accent color! Accent colors were introduced a few versions ago in Plasma, but now you can have Plasma automatically adjust the accent color from the current wallpaper:

If you use a wallpaper changer mechanism (like the one provided by Plasma), possibly by downloading new wallpapers (like Variety), you will get nice accent colors during the day. Here are a few examples produced running Variety to change the wallpaper:

Maybe it’s not an important feature, but, as we say in Italy, “Anche l’occhio vuole la sua parte” 😉

The last new feature that positively impressed me is that now KRunner also shows Java files (and probably other programming languages related files) when you search a string. Previously, although “Baloo” (the file indexing and file search framework for KDE) knew about these files, KRunner was only showing .txt files and a few others, but not Java files.

Concerning Wayland, one thing I noted is that if I start a Plasma Wayland session using a brand new user, it automatically scales the display in case of an HDPI screen. Wayland usability in Plasma has not improved since my last experiments (see KDE Plasma and Wayland: usability).

 

Xtext 2.27.0: update your Xbase compiler tests

If you update to Xtext 2.27.0 and have compiler tests for your Xbase DSL that assert the output of the compilation, you’ll get lots of failures after the update.

I am guilty of that 😉
Well, for a good reason, at least 🙂

In fact, I worked on this issue: https://github.com/eclipse/xtext-extras/issues/772 and its fix is included in Xtext 2.27.0.

Now, the Xbase compilation mechanism does not generate useless empty lines anymore (before, it added lines with two spaces). Your compiler tests will fail because the output is different.

I personally fixed my tests in my DSLs by simply using the Find/Replace mechanism of Eclipse with this substitution pattern (there are two space characters between the tab character and the newline character):

If you have deep nesting in your compilation output, you might have to repeat this substitution with more than two characters, but this should not be required unless you generate nested classes or something like that.

With the above substitution a test like the following one:

will become like the following one (you see the difference: no empty line with two characters between the two generated constructors:

Now your tests should be fixed 🙂

Configure Arch Pacman

Pacman is the package manager in Linux Arch and Linux Arch-based distributions.

I’ve been using EndeavourOS for some time, and I enjoy it. EndeavourOS is pretty close to vanilla Arch. I also experimented with pure Arch (more on that in future blog posts). However, the output of pacman in EndeavourOS is much more excellent and “eye candy” than in Arch. However, it’s just a matter of configuring /etc/pacman.conf a bit in Arch to have the “eye candy” output.

These are the options to enable in the [options] section in that file (the ParallelDownloads does not have to with the output, but it’s a nice optimization):

Without these options, this is the output of pacman (e.g., during an upgrade):

And this is the output with the options above enabled:

Besides the colors, you can spot c’s for the progress representing “Pacman,” the video-game character, eating candies (that’s the aim of the option ILoveCandy)… waka waka waka!  🙂

The colors are also helpful when searching for packages:

Happy Pacman! 🙂

macOS: switch between different windows of the same application

Maybe this is well-known to macOS users, but it wasn’t clear to me as a Linux user.

As a Linux user, I’m used to using Alt+Tab to switch between different windows. But I also use the shortcut to switch between different windows of the same application. In Gnome, the shortcut is Alt+<the key above Tab>, which is cool because it works with any keyboard layout. In KDE it is Alt+backtick (`), which has to be changed in Italian keyboards, like mine to Alt+\. Indeed, in the Italian keyboard layout, the key over tab is \.

In macOS it’s the same as in KDE: the shortcut is bound by default to ⌘+`, which of course it’s unusable in Italian keyboards (you should use a complex combination of keys only to insert the backtick ` character). You then have to configure the shortcut “Move focus to next window”, which is quite counterintuitive to me (I had always thought that it wasn’t possible in macOS to switch between windows of the same application if not by using the touchpad gesture or by pressing the down key after using the standard switcher):

Change it to something suitable for your keyboard layout. For the Italian layout I change it to ⌘+\:

And then you’re good to go! 🙂

KDE Plasma and Wayland: usability

It looks like KDE Plasma is getting usable with Wayland!

This is my current testing environment for this blog post:

Operating System: EndeavourOS
KDE Plasma Version: 5.24.5
KDE Frameworks Version: 5.94.0
Qt Version: 5.15.4
Kernel Version: 5.15.41-1-lts (64-bit)
Graphics Platform: Wayland
Processors: 8 × Intel® Core™ i7-8550U CPU @ 1.80GHz
Memory: 15,3 GiB of RAM
Graphics Processor: Mesa Intel® UHD Graphics 620

I had tested KDE Plasma with Wayland in the past, and the main problem I was experiencing, which made it unusable to me, was that I had to scale the display. I could scale the display, but the main problem was that, while KDE applications looked nice, the GTK applications looked blurred. This problem is still there, as you can see from this screenshot (here, I scaled the display to 150%):

You can see that the System settings dialog and Dolphin (in the background) look nice, but the EndeavourOS Welcome app and Firefox (in the background), which are GTK applications, look blurred!

Thus, I tried another way: I went back to 100% Display and tried to work on the Font HDPI scaling, though Plasma discourages doing that (it suggests using the display scaling). I tried with both 120 and 140 the result is satisfactory, as you can see from these screenshots:

IMPORTANT: You have to log out and log in to apply these changes. At least, I had to do that in my experiments.

There’s still one caveat to solve: GTK4 applications, like Gedit (the Gnome text editor) and Eye of Gnome (the Gnome image viewer), which, in this version of EndeavourOS, are already provided in their 42 version (using libadwaita). These applications are not considering font scaling. To solve that, you have to install Gnome Tweaks and adjust the “Scaling Factor” from there. Then, everything works also for those applications (Gedit is the one with “Untitled Document 1,” and Eye of Gnome is the dark window in the foreground):

With the Wayland session in Plasma, you can enjoy the default touchpad gestures (which, at the moment, are not configurable):

  • 4 Finger Swipe Left –> Next Virtual Desktop.
  • 4 Finger Swipe Right –> Previous Virtual Desktop.
  • 4 Finger Swipe Up –> Desktop Grid.
  • 4 Finger Swipe Down –> Available Window Grid.

Moreover, the scrolling speed for the touchpad can be configured (while, on X11, I wasn’t able to):

There are still a few strange things happening: the splash screen has the title bar and window buttons if you start Eclipse! 😀

I’ll try to experiment with this configuration also in other distributions.

Let’s cross our fingers! 😉

Dropbox and Gnome 42

Now that Gnome 42 has been released and available in most Linux distributions, I started experiencing problems with the Dropbox icon in the system tray.

First of all, I have no problem with Ubuntu 22.04, which comes with the extension “AppIndicator and KStatusNotifierItem Support” https://extensions.gnome.org/extension/615/appindicator-support/. Moreover, I think the problem is not there because, while Ubuntu 22.04 ships Gnome 42, it still ships Nautilus in version 41.

In Fedora and EndeavourOS, I usually install the same extension in the Gnome DE, and it has been working quite well.

Unfortunately, with Gnome 42 (provided by Fedora 36 and currently by EndeavourOS), I started experiencing problems, even with the extension above installed and activated.

If you had already installed Dropbox in your Gnome 41 DE and upgraded to Gnome 42 (e.g., you upgraded Fedora 35 to Fedora 36 after installing Dropbox), the icon is clickable. Still, you get a context menu always saying “Connecting…”

At least you can access “Preferences…”.

However, suppose you had never installed Dropbox in that Gnome 42 environment. In that case, the icon in the system tray appears (again, after installing the above extension), but no matter how you click on that, no context menu appears at all. That’s a disgrace because you cannot access Dropbox preferences, like “selective sync” (you have to use the command line, as I suggested in the previous post).

Instead of the extension “AppIndicator and KStatusNotifierItem Support” (disable it if you had already activated that), you can use the extension “Tray Icons: Reloaded,” https://extensions.gnome.org/extension/2890/tray-icons-reloaded/. Install it, activate it, logout and login, and now the context menu works as expected:

Remember that this extension does not seem to support all system tray icons. For example, Variety does not seem to be supported.

At least you can use this extension to set up Dropbox (e.g., selective sync) and then go back to the previous extension!

Testing the new Fedora 36

Fedora 36 has just been released, and I couldn’t resist trying it right away. I had already started using Fedora 35 daily (though I have several Linux distributions installed), and I’ve been enjoying it so far.

Before upgrading my Fedora 35 installations, I decided to install Fedora 36 on a virtual machine with VirtualBox.

These are a few screenshots of the installation procedure.

As usual, you’re greeted by a dialog for installing or trying Fedora, and I went for the latter.

The installation procedure is available from the dock:

To be honest, I’m not a big fan of the Fedora installer: compared to other installers like Ubuntu and EndeavourOS or Manjaro, I find the Fedora installer much more confusing. Maybe it’s just that I’m not used to such an installer, but I never had problems with Calamares in EndeavourOS or Manjaro, not even the very first time I tried Calamares.

For example, once a subsection is selected, the button “Done” is at the upper left corner, why I would expect buttons at the bottom (right).

I appreciate that you can select the NTP server time synchronization (at my University, I cannot use external NTP servers, and in fact, the default one is not working: I have to use the one provided by my University). Unfortunately, this setting does not seem to be persisted in the installed system. UPDATE 12/May: Actually it is persisted: I thought I’d find it in the file /etc/systemd/timesyncd.conf but instead it is in /etc/chrony.conf. Well done!

Since I’m installing the system on a VM hard disk for the partitioning, I chose the “Automatic” configuration. On a real computer, I’d go for manual partitioning. Even in this task, the Fedora installer is a bit confusing. Maybe the “Advanced Custom (Blivet GUI)” is more accessible than the default “Custom” GUI, or, at least, it’s much similar to what I’m accustomed to.

Finally, we’re ready to start the installation.

Even on a virtual machine, the installation does not take that long.

Once rebooted (actually, in the virtual machine, the first reboot did not succeed, and I had to force the shutdown of the VM), you’re greeted by a Welcome program. This program allows you to configure a few things, including enabling 3rd party repositories and online accounts and specifying your user account.

Then, there is the Gnome welcome tour, which I’ll skip here.

Here is the information about the installed system. As you can see, Fedora ships with the brand new Gnome 42 and with Wayland by default:

Fedora uses offline updates, so once notified of updates, you have to restart the system, and the updates will be installed on the next boot:

The installation is not bloated with too much software. Gnome 42 new theme looks fine, with folder icons in blue (instead of the old-fashioned light brown). Fedora also ships with the new Gnome Text Editor. Differently from the old Gedit, the new text editor finally allows you to increase/decrease the font size with Ctrl and +/-, respectively. I cannot believe Gedit did not provide such a mechanism. I used to install Kate in Gnome because I was not too fond of Gedit for that missing feature.

Instead, Fedora does not install the new Gnome terminal (gnome-console) by default. I installed that with DNF, and I wouldn’t say I liked it that much: with Ctrl +/-, you can zoom the terminal’s font, but the terminal does not resize accordingly. For that reason, I prefer to stay with the good old Gnome terminal (gnome-terminal).

First impressions

First of all, although I tried this installation in a VM, Fedora 36 seems pretty responsive and efficient. I might even say that the guest Fedora 36 VM looked faster than my host (Ubuntu 22.04). Maybe that was just an impression 😉

Since I chose the Automatic partitioning, Fedora created two BTRFS subvolumes (one for / and one for /home) with compression, and a separate ext4 /boot partition:

It also uses swap on zram:

I soon installed the extension “AppIndicator, KStatusNotifierItem and legacy Tray icons support to the Shell” by Ubuntu (https://extensions.gnome.org/extension/615/appindicator-support/) and it works in Gnome 42.

However, after installing Dropbox, while the icon shows on the system tray, clicking on that Dropbox icon (left or right-click or double-click) does not make the context menu appear, making that unusable. I seem to understand that it is a known problem, and maybe they are already working on that. For the time being, if you need the Dropbox context menu for settings like “selective sync,” you’re out of luck. However, you can use the dropbox command-line program for the settings. In that case, I first ignore all the folders and then remove the exclusion for the folders I want to have in sync.

For example, I only want “Screenshot” and “sync” from my Dropbox on my local computer, and I run:

On a side note, I find the Dropbox support for Linux a kind of an insult…

I look forward to upgrading my existing Fedora 35 installations on my computers, and maybe I’ll get back with more impressions on Fedora 36 on real hardware.

For the moment, it looks promising 🙂

Mirror Eclipse p2 repositories with Tycho

I had previously written about mirroring Eclipse p2 repositories (see this blog tag), but I’ll show how to do that with Tycho and one of its plugins in this post.

The goal is always the same: speed up my Maven/Tycho builds that depend on target platforms and insulate me from external servers.

The source code of this example can be found here: https://github.com/LorenzoBettini/tycho-mirror-example.

I will show how to create a mirror of a few features and bundles from a few p2 repositories so that I can then resolve a target definition file against the mirror. In the POM, I will also create a version of the target definition file modified to use the local mirror (using Ant). Moreover, I will also use a Tycho goal to validate such a modified target definition file against the local mirror. The overall procedure is also automatized in the CI (GitHub Actions). This way, we are confident that we will create a mirror that can be used locally for our builds.

First of all, let’s see the target platform I want to use during my Maven/Tycho builds. The target platform definition file is taken from my project Edelta, based on Xtext.

As you see, it’s rather complex and relies on several p2 repositories. The last repository is the Orbit repository; although it does not list any installable units, that is still required to resolve dependencies of Epsilon (see the last but one location). We have to consider this when defining our mirroring strategy.

As usual, we define a few properties at the beginning of the POM for specifying the versions of the plugin and the parts of the p2 update site we will mirror from:

Let’s configure the Tycho plugin for mirroring (see the documentation of the plugin for all the details of the configuration):

The mirror will be generated in the user home subdirectory “eclipse-mirrors” (<destination> tag); we also define a few other mirroring options. Note that in this example, we cannot mirror only the latest versions of bundles (<latestVersionOnly>), as detailed in the comment in the POM. We also avoid mirroring the entire contents of the update sites (it would be too much). That’s why we specify single installable units. Remember that also dependencies of the listed installable units will be mirrored, so it is enough to list the main ones. You might note differences between the installable units specified in the target platform definition and those listed in the plugin configuration. Indeed, the target platform file could also be simplified accordingly, but I just wanted to have slight differences to experiment with.

If you write the above configuration in a POM file (a <packaging>pom</packaging> will be enough), you can already build the mirror running:

Remember that the mirroring process will take several minutes depending on your Internet connection speed since it will have to download about 500 Mb of data.

You can verify that all the specified repositories are needed to create the mirror correctly. For example, try to remove this part from the POM:

Try to create the mirror, and you should see this warning message because some requirements of Epsilon bundles cannot be resolved:

Those requirements are found in the Orbit p2 repository, which we have just removed for testing purposes.

Unfortunately, I found no way to make the build fail in such cases, even because it’s just a warning, not an error. I guess this is a limitation of the Eclipse mirroring mechanism. However, we will now see how to verify that the mirror contains all the needed software using another mechanism.

We create a modified version of our target definition file pointing to our local mirror. To do that, we create an Ant file (create_local_target.ant):

Note that this also handles path separators in Windows correctly. The idea is to replace lines of the shape <repository location=”https://…”/> with <repository location=”file:/…/eclipse-mirrors”/>. This file assumes the original target file is example.target, and the modified file is generated into local.target.

Let’s call this Ant script from the POM:

Finally, let’s use Tycho to validate the local.target file (see the documentation of the goal):

Now, if we run:

we build the mirror, and we create the local.target file.

Then, we can run the above goal explicitly to verify everything:

If this goal also succeeds, we managed to create a local mirror that we can use in our local builds. Of course, in the parent POM of your project, you must configure the build so that you can switch to local.target instead of using your standard .target file. (You might want to look at the parent POM of my Edelta project to take some inspiration.)

Since we should not trust a test that we never saw failing (see also my TDD book 🙂 let’s try to verify with the incomplete mirror that we learned to create by removing the Orbit URL. We should see that our local target platform cannot be validated:

Alternatively, let’s try to build our mirror with <latestVersionOnly>true</latestVersionOnly>, and during the validation of the target platform, we get:

In fact, we mirror only the latest version of org.antlr.runtime (4.7.2.v20200218-0804), which does not satisfy that requirement. That’s why we must use with <latestVersionOnly>false</latestVersionOnly> in this example.

For completeness, this is the full POM:

And this is the YAML file to build and verify in GitHub Actions:

I hope you found this post valuable, and happy mirroring! 🙂

Multibooting with GRUB

Besides Windows (which I rarely use) on my computers, I have a few Linux distributions. Grub 2 does a good job in booting Windows and Linux, especially thanks to os-prober, in autodetecting other operating systems in other partitions of the same computer. However, there are a few “buts” in this strategy:

  1. Typically, the last installed Linux distribution, say L1, installs its own grub as the main one, and when you upgrade the kernel in another Linux distribution, say L2, you have to boot into L1 and “update-grub” so that the main grub configuration learns about the new kernel of L2. Only then can you boot the new kernel of L2. Of course, you can change the main grub by reordering the EFI entries, e.g., by using the computer’s BIOS, but again that’s far from optimal.
  2. Not all Linux distributions’ grub configurations can boot other Linux distributions. For example, Arch-based distros like EndeavourOS and Manjaro can boot Ubuntu-based distros, but not the other way round (unless you fix a few things in the grub configuration of Ubuntu)! Recently, I started to use also Fedora. I found out that os-prober in Ubuntu and EndeavourOS does not detect the configurations correctly to boot Fedora: recently, Fedora switched to “blscfg” (https://fedoraproject.org/wiki/Changes/BootLoaderSpecByDefault), and as a result, Ubuntu and EndeavourOS create grub configurations that do not consider the changes you made in Fedora’s /etc/default/grub.

That’s why I started to experiment with grub configurations. I still have a “main grub” in a Linux installation, which simply “delegates” to the grub configurations of the other Linux installations. This way, I solve both the two problems above!

In this blog post, I’ll show how I did that. Note that this assumes you use EFI boot.

I have Windows 10, Kubuntu, EndeavourOS, and Fedora on the same computer in this example. I will configure the grub installation of Fedora so that it delegates to Windows, Kubuntu, and EndeavourOS, without relying on os-prober.

This is the disk layout of my computer so that you understand the numbers in the grub configuration that I’ll show later (I omit other partitions like Windows recovery).

The key point is modifying the file /etc/grub.d/40_custom. I guess you already know that you should not modify directly grub.cfg, because a system update or a grub update (e.g., “update-grub”) will overwrite that file.

The file /etc/grub.d/40_custom already comes with some contents that must be left as they are: you add your lines after the existing ones. For example, in Fedora, you have:

We will use the option configfile of grub configuration (see https://www.gnu.org/software/grub/manual/grub/grub.html#configfile): “Load file as a configuration file. If file defines any menu entries, then show a menu containing them immediately.” The Arch wiki also explains it well:

If the other distribution has already a valid /boot folder with installed GRUB, grub.cfg, kernel and initramfs, GRUB can be instructed to load these other grub.cfg files on-the-fly during boot.

The idea is to put in /etc/grub.d/40_custom an entry for each Linux distribution, pointing to the grub.cfg of that distribution, after setting the root partition. Thus, the path to the grub.cfg must be intended as an absolute path in that partition. If you look at the partition numbers above, these are the two entries for booting EndeavourOS and Kubuntu:

NOTE: the “rmmod tpm” is required to avoid TPM errors when booting those systems (“Unknown TPM error”, “you need to load the kernel first”). It happened on my Dell XPS 13, for example. Adding that line (i.e., not loading the module “tpm”) solved the problem.

Remember that the path assumes that the /boot directory is not mounted on a separate partition. If instead, that’s the case, you probably have to remove “/boot”, but I haven’t tried that.

Concerning the entry for Windows, here it is:

In this entry, the root must correspond to the EFI partition, NOT to the partition of Windows.

Save the file and regenerate the grub configuration. In other Linux distributions, it would be a matter of running “update-grub,” but in Fedora, it is:

Now reboot, and you should see the grub menu of Fedora and then, at the bottom, the entries for EndeavourOS, Kubuntu, and Windows. Choosing “EndeavourOS” or “Kubuntu” will NOT boot directly in these systems: it will show the grub menu of “EndeavourOS” or “Kubuntu.”

If you upgrade the kernel on one of these two systems, their grub configuration will be correctly updated. There’s no need to boot into Fedora to update its grub configuration 🙂

If you want to configure the grub in another Linux distribution, please remember that Fedora stores the grub.cfg in /boot/grub2 instead of /boot/grub, so you should write the entry for Fedora with the right path. However, if you plan to boot Fedora with this mechanism, you should disable “blscfg” in the Fedora grub configuration, or you will not be able to boot Fedora (errors “increment.mod” and “blscfg.mod” not found).

Now that we verified that it works, we can remove the entries generated by os-prober. In /etc/default/grub add the line:

and regenerate the grub configuration.

If you want grub to remember the last choice, you can look at this post.

On a side note, due to the way Fedora uses grub (https://fedoraproject.org/wiki/Changes/HiddenGrubMenu), without os-prober, you will not see the grub menu unless you press ESC. After the timeout, it will simply boot on the default entry. To avoid that and see the grub menu, just run:

And the grub menu will get back as usual.

Then, you can also remove os-prober in the other Linux installations, since that is useless now.

These were the original grub menus of Fedora and EndeavourOS, before applying the modifications described in this post:

Pretty crowded!

And this is the result after the procedure described in this post (note that from the Fedora grub menu you select EndeavourOS to land its grub menu and Kubuntu to land its grub menu):

Much better! 🙂

 

Getting started with KVM and Virtual Machine Manager

After playing with VirtualBox (see my posts), I’ve decided to try also KVM (based on QEMU) and Virtual Machine Manager (virt-manager).

The installation is straightforward.

In Ubuntu systems:

In Arch-based systems:

Then, you need to add your user to the corresponding group:

Reboot, and you’re good to go.

In this post, I’m going to install Fedora 35 on a virtual machine through Virtual Machine Manager (based on KVM and QEMU).

So, first, download the ISO of this distribution if you want to follow along.

Let’s start Virtual Machine Manager (virt-manager):

Press the “+” button to create a new virtual machine, and we select the first entry since we have downloaded an ISO.

Here, we select the ISO and let the manager detect the installed OS. Otherwise, we can choose the OS manually (the manager might not catch the OS correctly in some cases: it happened to me with ArcoLinux, for example).

Then, we allocate some resources. Since I have 16GB and a quad-core, I give the virtual machine 8GB and two cores.

Then, we allocate storage for the machine. Alternatively, we can select or create a custom image file in another location. By default, the image will NOT occupy the whole space physically on your disk. Thus, I will not lose 60GB (unless I’ll effectively use such a space on the virtual machine). The file will appear of the specified size on your drive, but if you check the free disk space on your drive, you will note that you haven’t lost so many Gigas (more on that in the next steps).

In the last step, we can give a custom name to our machine and customize a few settings before starting the installation by selecting the appropriate checkbox (we also make sure that the network is configured correctly).

If we selected “Customize configuration before install,” by pressing “Finish,” we get to the settings of our virtual machine.

In this example, I’m going to change the chipset and specify a UEFI firmware:

We can also get other information, like the path of the disk image:

And we can click “Begin Installation.” After the boot menu, we’ll get to the live environment of the distribution ISO we chose:

You can also specify to resize the display of the VM automatically if you resize the window and when to do that. (WARNING: this will work correctly only after installing the OS in the virtual machine since this feature requires some software in the guest operating system. Typically, such a software, spice-vdagent, is automatically installed in the guest during the OS installation, from what I’ve seen in my experiments.)

And we can start the installation of the distribution (or try it live before the actual installation), as usual. Of course, the whole installation process will be a bit slower than on real hardware.

I’ll choose the “Automatic” choice for disk partitioning since the disk image will be allocated only to this machine, so I will not bother customizing that.

While installing, you might want to check the disk image size and the effective space on the disk:

After a few minutes, the installation should be complete, and we can reboot our virtual machine

And upon reboot, we’ll get to our new installed OS on the virtual machine:

In the primary Virtual Machine Manager window, you can see your virtual machines, and, if they are running, a few statistics:

In the virtual machine window’s “View” menu, you can switch between the “Console” view (that is, the virtual machine installed and running OS) and the “Details” view, where you can see its settings, and change a few of them.

Note that now the automatic resize of the machine display and the window works: in the screenshot I resized the window (made it bigger) and the display of the machine resized accordingly.

When you later restart a virtual machine from the manager, you might have to double-click on the virtual machine element and possibly switch to the “Console” view.

After installing the OS, you might want to check the image file and the actual disk usage again. You will find that while the image file size did not change, the disk usage has:

What I’ve shown in this blog post was one of my first experiments with KVM and the Virtual Machine Manager. To be honest, I still prefer VirtualBox, but maybe that’s only because I’m more used to VirtualBox, while I’ve just started using virt-manager.

That’s all for now! Stay tuned for further posts on KVM and virt-manager, and happy virtualization! 🙂