Kernel Virtual Machine storage pool for guests

Using KVM and libvirt with commands like virsh and virt-install.
I create two dirs in the file system; ‘vms’ and ‘iso’, and then create a directory based storage pool pointing to ‘vms’. I put the o/s iso files into the ‘iso’ dir.

When I create a guest using virt-install, it puts the vm into the ‘vms’ storage pool as expected, BUT it also creates a second storage pool called ‘iso’, which was unexpected. I can’t find anywhere in the docs saying the iso files should be in a pool, or that one will be created. Should I just create an ‘iso’ storage pool at the beginning?

Yes, ISO’s require a storage pool. As per my virt-manager shot here:

as you can see my ISO pool is in /data/iso on my machine, but you can set this to wherever you want. I think by default it would be somewhere under /var/lib/libvirt/images.

Thanks, it’s very clear in the screenshot. I’d been avoiding virt-manager because it’s deprecated by RHEL.
https://blog.wikichoon.com/2020/06/virt-manager-deprecated-in-rhel.html
I’ll create a storage pool for ‘iso’ as part of the initial setup.

I’ve never had “ISO pool” in libvirt. Probably due to not using ISOs.

Well deprecated by RHEL as in removed from the repos to force you to use cockpit. Which they use for ovirt etc.

For all other distros it is still relevant and all other distros still give you the option to choose virt-manager or cockpit depending on what you prefer. Sadly RHEL don’t let you make the choice on what you use but rather remove it forcing you to use something else.

The project is still alive just RHEL don’t want to let you use it.

2 Likes

I keep 'em all (ISOs,qcow2s,raw) in whichever directory seems sensible - sometimes in the same directory.

Cockpit is not a fit replacement for VMM yet.

VMM makes it very easy to create and put pools wherever the space is.

The default location isn’t ideal as you can quickly eat up space on your / volume with VM images ( unless you specifically move that dir to another volume ).

The cockpit web interface; for some reason I didn’t want to use it, so I’ve been trying to make everything work with command line.

Rather odd. RH bought the company that developed kvm, virt, etc. virt-manager was originally written in java. They paid to convert the code to python (if memory serves made correct) and make platform independent when they open sourced it. Originally virt-manager only ran on M$ Winders though kvm was linux. Seems to be wasted time and money for a decent tool. I’ll have to take a look at cockpit.

Do you confuse Virtual Manager (GUI Application) with oVirt engine (management part of oVirt)? What you describe matches the history of the latter AFAIK.

You are so correct. It’s been a few years. Thank you for commenting.

I just loaded cockpit. Nice idea, but doesn’t stack up to virt-manager for a graphical tool.

Does virt-manager, which depends on Python and GTK3, run anywhere but Linux platforms? That limits the clients that you can use to manage your servers.

The cockpit can be accessed with a browser from any client? Furthermore, cockpit attempts to configure everything of any server, not just manage KVM/Xen/LXC. Alas, like NetworkManager and FirewallD before it, cockpit’s feature set sounds to be lacking. Might become good in the future. Just might.

(I don’t use cockpit. Found Ansible for overall config management. RHEL [8] documentation has got sections about use of Ansible, so Red Hat seems to invest into it.)

Yep, Red Hat acquired Ansible back in 2015: Why Red Hat Acquired Ansible

Now it’s also what they base their RHCE exam on.

Yes, if firewall allows.

With virt-manager you can (after setting up authentication) manage VMs on remote hosts. That feature is lacking from cockpit it seems. This means you have to install this cockpit webservice on every server running kvm. As a serveradmin I find that not so great, it’s another service running increasing the attack surface.