[HowTo] Getting Started with Virt-Manager & QEMU-KVM

[pbear]

There are several options for running virtual machines in Linux. Early on, I went with VirtualBox because I was still mostly a Windows user and VBox works in both OSs. Later, when I looked into QEMU-KVM, I was discouraged by how difficult it seemed, as all the tutorials were either superficial or brilliant-but-very-complicated. Recently, no longer much of a Windows user, I decided to give Virt-Manager another shot. Was pleasantly surprised to discover QEMU isn't difficult after all. Indeed, all things considered, it's easier than VBox. What's difficult is finding a tutorial in the Goldilocks spot between superficial and overwhelming. This is my attempt at such a tutorial.

Note: Realistically, a tutorial like this only makes sense if you're looking at the dialogue boxes while reading it. So, open Virt-Manager in one window and the tutorial in another (or on your phone). I think you'll find everything comes together pretty easily. The folks who designed Virt-Manager did a good job with the GUI. If you need help, feel free to open a thread on the Forum. Please post in the support section, though, not here.

Overview. In a nutshell, we're going to:

• Install Virt-Manager.
• Configure Virt-Manager.
• Create a VM.
• Configure the VM.

Terminology. VM = virtual machine. KVM = a function of the Linux kernel which give VMs direct access to RAM and the CPU (a type-one hypervisor). QEMU = an app which emulates other hardware functions, e.g., a file which serves as VHD (virtual hard drive); QEMU is a type-two hypervisor. Virt-Manager = a GUI front-end for QEMU. A command line (CLI) front-end (virsh) is brought in by the same packages as install Virt-Manager, but I'm not going to discuss that here. libvirt = the main QEMU project; also, the label used for most folders holding QEMU files, e.g., /etc/libvirt. VM-Page = each VM's sub-page when opened from Virt-Manager's main page.

Installation. Sources differ somewhat on which packages they recommend for installing Virt-Manager. I've been happy with this command string (recommended by CwF):

Code: Select all

sudo apt install virt-manager qemu-system-x86 qemu-utils libvirt-daemon-system

This brings in nearly a hundred dependencies, is a 60 MB download, and installs to a little more than 200 MB of space on the system partition. FYI, virsh comes in with libvirt-client, a dependency of virt-manager.

Configuration. To open Virt-Manager, select from Menu (add to panel, if you like). Click on QEMU/KVM (a connection, in Virt-Manager lingo). Now you can access settings through the menu at top, e.g., File > New Virtual Machine.

By default, Virt-Manager stores VHDs in /var/lib/libvirt/images. VHDs are very large. As in, a 30 GB VHD = a file that size. This isn't usually a problem if you're using a single large system partition, but if you have split off home and/or data to a separate partition, your system partition probably doesn't have room for VHD files. The solution is to open Edit > Connection Details > Storage and add a new location ("pool") for VHDs. If feasible, a separate partition makes backup of regular data files simpler, but a mere folder on an already-present home or data partition also works.

Authorization. By default, Virt-Manager requires an admin password (root or sudo) to open. Generally, though, you want to run it as a regular user. There are a couple ways to do that, including user-session and polkit. The simplest (imho) is to add yourself to the libvirt group, sudo adduser $USER libvirt. Other users, even those without admin privileges, can be given Virt-Manager access by adding them to the same group. Be aware, although members of the libvirt group may use Virt-Manager without password authorization, the VM files (including VHDs) will be owned by user-root.

Autostart Network. Virt-Manager uses a virtual network adapter to give VMs internet access (piggy-backing on the host's access). By default, the virtual adapter is disabled (kinda silly). Enable with Edit > Connection Details > Virtual Networks > tick box to Autostart On Boot; click Apply. Won't take effect, though, until reboot host. Enable for this boot with sudo virsh net-start default.

For virtualization to work, it must be enabled in the firmware (UEFI/BIOS). Most computers ship with virtualization enabled by default, but a few do not. If unsure, open firmware settings and find the relevant entry. On some computers, an admin password must be set before settings can be modified (see computer manual for how-to).

Creating a VM. For your first VM, create a test box you won't mind deleting if it doesn't work out. From the main page, File > New Virtual Machine. Opens a wizard with five steps:

1. How to install. Usually local install media (for a new VM), but also can re-use an existing VHD (fresh start for VM settings).

2. Choose ISO (for new VM). Click Browse, which will take you to the Storage page mentioned above. First time, add a pool for location where you generally save ISO files. The same pool can be used for future installations. Select ISO from list; click Choose Volume. Will return to Step 2 box. Choose OS to install, meaning type of OS. AFAICT, automatically detect (the default) never works. Instead, untick and use search box. For Bookworm, I use debiantesting, which apparently Deb12 was when Virt-Manager was last updated. Click Forward button.

3. Choose memory and CPU settings. As a rule of thumb, assign half the available resources to the VM, reserving the other half for host. If that's not enough for either side, you shouldn't be using virtualization. Consider dual boot or full install to USB drive instead. Conversely, a super-duper gaming rig might be able to split RAM and CPU three or four ways.

4. Storage (VHD). Tick Select or create custom storage, then click Manage. Will take you (again) to the Storage page. Now is when you will select the pool created during the Virt-Manager configuration stage. Click + button to create a new VHD file; enter name, replacing debiantesting (for example) with a useful identifier, e.g., Deb12-Gnome. Leave format as qcow2 (unless you have very good reason for choosing raw). Don't bother with a backing store. Select capacity; my preference for most current Linux systems is 30 GB; can get away with 20 GB (the default) if don't plan to install much. I leave Allocate Now unticked (same as quick format, afaict, not dynamic disk sizing as in VBox). Click Choose Volume; will return to Step 4 box; click Forward.

5. Ready to begin. Enter VM name, usually the same one as used for the VHD, again replacing OS type (which is the default). Notice box to Customize configuration. This where you can select boot mode (UEFI instead of BIOS, the default). You also can set up a shared folder (see below), if planning to use one. Click Begin Installation (upper-left).

IMHO, there's not much reason for ordinary folks to use UEFI mode. It's mainly intended for developers, so they can confirm apps, drivers, etc. are secure boot compatible (or test registering them with MOK). FYI, there's a UEFI mode without secure boot (last option in a dropdown on the Configuration box), but it's incompatible with internal snapshot (see below).

Installer will go through the same steps as a regular installation. VHD will be assigned a device ID of vda (as distinguished from sda). Can be partitioned the same as a regular drive (GPT or MBR), including encryption. It's even possible to have more than one VHD, or share a VHD between two VMs. For now, just run the installer. Sometimes the installer session hangs at shutdown (rather than rebooting); in that case, use Force Off (menu or icon).

Configure VM. Most configurations come in with the operating system, same as installing to bare metal, but a few things are different for VMs.

First, a quick spin around the block. Open VM-Page; select run, either from menu (first row) or by clicking icon (second row). Usually Virt-Manager will switch automatically to Console view (showing the VM's desktop), but sometimes have to switch manually. Indeed, can switch manually at any time among Console view (desktop), Details (hardware and system info) and Snapshots while the VM is running. Also can switch to Virt-Manager itself or any other app running on the host. Will switch automatically if mouse-click somewhere outside Console (e.g., an icon on host's panel). Or tap Left-Ctrl+Left-Alt simultaneously, then Alt-Tab to cycle through open apps on host.

Display mode. By default, the VM desktop will display about 2/3's normal size, readable but smaller than the available space. There is a full screen mode, but it's relatively low resolution. (If enter accidentally, escape is with a pop-up at upper-center of screen, only visible when moused over.) The better solution is to install two packages in the VM: sudo apt install qemu-guest-agent spice-vdagent. Debian's standard installer will have installed the first one automatically, so only need to add the second. Reboot. From menu, select View > Scale Display > Auto resize. [This works with Gnome, Cinnamon and Flashback, but not the other desktops; there are workarounds for the latter, but they're a bit complicated.] By the way, the agent packages also enable copy to/from the host (using clipboard).

Shared Folders. A neat trick for accessing files on host. From the VM-Page, open Hardware Settings. Click Memory; tick box to enable sharing; click Apply. Click Add Hardware (lower-left); select Filesystem (two-thirds of the way down list); select source path (from Storage); give a label, e.g. data-files (misleadingly, called target path, but it's really just a label); click Finish. Boot VM. Create mount point. Can mount the share manually or add to fstab. For example, I have a data partition which mounts to /data/files on host. Storage label for the share in Virt-Manager is data-files (creative, eh?). Mount point for the share is a folder in Home called Data. Mount with:

Code: Select all

sudo mount -t virtiofs data-files $HOME/Data  #  to test, before adding to fstab
echo "data-files   /home/pbear/Data   virtiofs   noatime,nofail   0   0" | sudo tee -a /etc/fstab

File permissions pass through with the share. This works for me because I'm the primary user (uid=1000) in both host and guest. To state the obvious, do not access the same files at the same time in both host and guest. To mount read-only, add ro, (no space) before noatime. Also, be advised the virtiofs method only works if both host and guest are using at least the 5.4 kernel. If that's not true in your case, look into 9p (which is the older solution).

Other tips. Not trying to cover everything, but a few pointers.

USB devices. Can be attached to a VM with Virtual Machine > Redirect USB device. Works with drives, printers, and other peripherals. Works in a live session as well as an installed system. Device isn't available to host while attached to a VM. Storage media can be shared simultaneously, though, by adding host's /media folder (or other mount location) as a shared folder (I don't bother).

Snapshots. A handy feature of VMs is the ability to try something - installing an app, say - then unwind the trial with the click of a button. If you're familiar with snapshot in VBox, be aware Virt-Manager does it a little differently. Rather than a separate file with changes, Virt-Manager snapshots are internal, using a copy-on-write mechanism similar to btrfs. (QEMU can do external snapshots, but they're not supported by Virt-Manager.) To revert, right-click snapshot and select Start; or tap Run button at lower-left. To keep changes, simply delete the snapshot.

Windows. The walk-through above assumes both host and guest are running Linux. Virt-Manager can accommodate a Windows guest, but the steps are a bit different. Also, unless using GPU passthrough, performance reportedly isn't as good as VBox, so I'm continuing to use that for my Win10 VM. If you want to pursue Windows-in-Virt-Manager, there are many articles on the internet.

References: Website, GitHub, KVM, QEMU, libvirt, virsh, Debian, Arch, Gentoo, Manjaro, GPU passthrough.

Edited to clarify a few points, reflect feedback, and correct a few grammar or diction errors.

[lindi]

Authorization. By default, VirtMan runs as user-root. Generally, though, you want to run it as a regular user.

VirtMan is the GUI, it runs as normal user by default. What is running as root is libvirtd.

[pwzhangzz]

The simplest (imho) is to add yourself to the libvirt group, sudo adduser $USER libvirt.

This should be sudo adduser libvirt $USER . My fault.

Thanks for taking time to write this tutorial I have been looking for it for a while.

[sunrat]

The simplest (imho) is to add yourself to the libvirt group, sudo adduser $USER libvirt.

This should be sudo adduser libvirt $USER . My fault.

The adduser command syntax is

Code: Select all

adduser user group

Different from the usermod command which is

Code: Select all

usermod –a –G group user

[cfb]

I don't think you should use the name "VirtMan". The proper name is either "Virtual Machine Manager" or "virt-manager".
If you do a search for "VirtMan" you will see that it is something else.

[pbear]

I don't think you should use the name "VirtMan". The proper name is either "Virtual Machine Manager" or "virt-manager".
If you do a search for "VirtMan" you will see that it is something else.

This is a tough one. Fact is, I didn't know that. OTOH, I'm not the only one to use VirtMan for Virt-Manager. It's four of the first six hits on an internet search. I'll consider using the longer label - indeed, it's how i wrote the tutorial originally. For the time being, valid point and users should be aware another project uses the name. FWIW, I use Virt-Manager rather than VirtMan for searches.

VirtMan is the GUI, it runs as normal user by default. What is running as root is libvirtd.

Got it, thanks. Will correct when I do my first round of clean-up edits.

[barlafuss]

interesting, thanks

[lindi]

Got it, thanks. Will correct when I do my first round of clean-up edits.

And btw, you can use libvirtd without root privileges as well. Just select File->Add Connection... and choose QEMU/KVM user session. In fact, this is the default setting for gnome-boxes which is also a good GUI for libvirtd (bit simpler, easier to use than virt-manager). The main downside is that you cannot do advanced network setups without root privileges.

[CwF]

my first round of clean-up edits.

Good job, glad to hear it will be an ongoing effort! Glad to hear you've made the jump.

So many details!

On permission; libvirt has a very complete set of polkit policies at this point. I *think* this does eliminate most permission issues if the user is enabled through polkit. I don't think joining the libvirt group is required any more. I have yet to actually remove the group rights in my test, yet. There are other factors. For storage, I've started formatting 'pool' as owned by staff, formerly the common group was libvirt. So incomplete conclusion there.

I hit on more later if you don't mind.

[pbear]

@lindi: Thanks for the tip. Not something I've seen mentioned in any of my research. Is there an advantage to doing it that way rather than adding users to the libvirt group?

@CwF: Thanks for asking. I made a conscious decision not to discuss polkit, as the tutorial is intended for folks new to VirtMan and/or Linux. Indeed, I would prefer to stay away from all advanced topics and held several clever tricks out of the tutorial, on the theory newbies can only juggle so many balls before they all drop. If you do a separate thread/tutorial on advanced topics and want post a link here, that would be fine.

[lindi]

@lindi: Thanks for the tip. Not something I've seen mentioned in any of my research. Is there an advantage to doing it that way rather than adding users to the libvirt group?

I guess the main advantage is that if you have multiple users on the machine they can have their own VMs completely isolated from each other. Also disk images will be in your home and owned by your user so backing up /home is sufficient.

[pbear]

... with virt-manager, the following error msg is received:

Please open a separate thread in the support section of the Forum. It's the right place and more likely to be noticed by others. I may be able to help also.

... main advantage is that ... disk images will be in your home and owned by your user ...

I think most users would prefer that. I'll play with it in a test box (my main system is single user) and probably incorporate into the tutorial. Main question (to my mind) is whether to make this the primary recommendation (would still give add-to-libvirt-group as an alternative) or the other way 'round. Thanks again for the tip.

[pbear]

Having wrestled with this for several days, I'm going to explain how to enable auto-resize in desktops where it doesn't work out-of-the-box, which turns out to be most of them. This is somewhat advanced stuff, but not rocket surgery. Besides, a VM at less than full size is frustrating, so worth a little effort to get running correctly. I assume you have installed qemu-guest-agent and spice-vdagent, as mentioned in the main tutorial.

A simple solution, which works in most cases (but not KDE), is to run xrandr --output Virtual-1 --auto in Terminal. Has to be run after each boot, though, so not convenient. Can be placed in a panel or desktop launcher, but that's only a little more convenient. To my mind, the best solution is crontab, which will run the command string automatically at boot. First, using your favorite text editor, create a file with these two lines:

Code: Select all

#!/bin/bash
xrandr --output Virtual-1 --auto

Save in your home folder. Can be called almost anything. I use auto-resize.sh. Then make the file executable: chmod +x auto-resize.sh. Notice, no sudo. Not needed, it's your file.

Next, run crontab -e (again, no sudo). At prompt, select nano as text editor. Add a new line at end of the file: @reboot sh /home/pbear/auto-resize.sh (replace pbear with your username, of course). Ctrl-O to save (write-Out) ; tap Enter key to confirm over-write file ; Ctrl-X to exit. FYI, user crontab files are save in /var/spool/cron/crontabs, but shouldn't be edited directly. Use crontab -e. Reboot to test.

KDE is more complicated. This is the best solution I've seen, so it's what I'm going to describe here.

• Modify VM settings: Display Spice > Address > Localhost only ; Video > QXL. Other settings might work also, but the defaults don't.
• Run sudo systemctl status spice-vdagent. Notice enabled but inactive (dead). This is the main problem.
• Run kate /usr/lib/systemd/user/plasma-core.target ; add spice-vdagent.service to end of Wants= line ; enter sudo password when prompted.
• Create auto-resize.sh file as described above, saving in Home. Make executable.
• Settings > Startup and Shutdown > Autostart > Add... > Add Application... > Open file dialog > choose script + tick box to Run in Terminal. Reboot to test.

This procedure works with Plasma (X11). There's probably a way to get something like it to work with Plasma (Wayland), but I can't find it. Doesn't help that I don't run KDE, except occasionally in test boxes.
If anyone knows (or figures out) the trick, please share. Meanwhile, it's just a VM. Take the easy way out and run it with Plasma (X11).

[CwF]

enable auto-resize

Both virt-viewer and virt-manager console view have 'View>Scale Display>Always' where the guest is oblivious to the change...? I tend to leave guest alone so that wherever and however they are viewed, the viewer does the job - like scaling a video.

Actually, virt-viewer has no setting it just does it by default.

[pbear]

@CwF, thanks for the tip. I'm chagrined to confess, it never occurred to me to see what ticking that option does. Certainly, it's easier and faster. Notably, works with Plasma-Wayland in KDE, so a nice clean answer for that scenario. OTOH, the graphics resolution is lower than auto-resize. Also, while it uses more of the available space than standard view, a fair amount of real estate still goes unused, at least on my wide screen monitor. Last but not least, in KDE, vdagent being inactive also prevents copy-and-paste (to or from host) from working; Scale Display > Always doesn't help with that problem.. Not an issue for the other desktops, though.

Bottom line, like a lot of things, which strategy to choose will depend on how the VM is being used.

[CwF]

OTOH, the graphics resolution is lower than auto-resize. Also, while it uses more of the available space than standard view, a fair amount of real estate still goes unused, at least on my wide screen monitor

For all of those issues, set the guest resolution the same as the real host desktop, set dpi, and visit dpkg-reconfigure console-setup just the same as if it were on the bare metal.

in KDE, vdagent being inactive

Why, what issue does the agent have with KDE?
The agent isn't used or related to the host viewer rescaling since the guest is not changing resolution.

[pbear]

For all of those issues ...

Anyone using the tutorial is welcome to do as you suggest. Personally, the xrandr script seems easier.

Why, what issue does the agent have with KDE?

It's the other way around, KDE doesn't run the vdagent. I have no idea why. Frankly, I think it's pretty shitty the KDE developers can't be bothered to solve the problem.

[CwF]

It's the other way around, KDE doesn't run the vdagent.

See, this why I need notes!
I had run across this a year back when I had an itch to try some KDE. The itch is gone. I thought of trying a ~/profile invocation of the agent as user...no need.
The fragmentation continues...