virt-manager started with “sudo”, running as my normal user prevents from nearly everything, virtual networks etc.
All my “storages” are on an external usb3 hdd, user-mounted. Not enough disk space on default locations like /var/lib/libvirt/images.
Created a StoragePool, have some virtual disks below.
When I create a new VM and assign one or more of these virtual disks, a message pops up telling me that this storage “might not be inside search path” (translated from German), and offers to automatically fix it. Works fine than, until afaik the next reboot.
When I mount the usb3 hdd after reboot, “sudo virt-manager” and try to start any vm using one of that storage, I’m getting an “Error: Cannot access storage file … (as uid:… gid:…): Permission denied” error.
Simple Workaround is to remove affected virtual hdd from vm, and re-add it. When re-adding, as when creating a new vm, the “might not be inside search path” pops up, and “fixes” the issue.
Until next reboot, at least, can’t trigger without reboot, tried unplug/plug again usb3 hdd, stop/start libvirtd, no msg again.
Is this a bug?
Found that after a reboot, whyever, the ownership of the affected qcow2 files on the usb3 hdd is root.root, when the “auto-fix” is applied, they’re changed to qemu.qemu as long as the vm’s using these vdisks are running. Changed back to root.root automatically after shutdown.
I even tried to manuall chown -R qemu.qemu for the StoragePool folder, no solution, same error. Which I can’t understand at that point, as the error msg is misleading… confusing
You didn’t state what virtualization you’re running, but from your description is likely a libvirt managed KVM or Xen.
In general,
libvirt has to assume “best practices” that storage pools are configured on reliable storage.
User mounted storage cannot be considered “reliable” because until a User mounts the storage, it’s not available.
So,
You need to fix that problem…
You can try to mount your drive with an fstab entry, then remake your storage pools…
Personally, I’ve just tried to avoid the problem in the first place by properly provisioning the HostOS machine, and if I needed to expand then how it’s done would depend on the features of the machine.
I remember a long time ago I once linked the default location to the new location and that might have avoided permissions problems (hard to remember it was so long ago), but of course that won’t solve your “reliability” issue by itself… You should mount your storage location on boot as part of your system.
You’ve caught me Reason why I didn’t state is that I’m somewhat confused about the differentiation between libvirt(d), XEN, KVM, QEMU, and, got recommendations for, Virtualbox. Not sure what component is doing what, is virt_manager part of …? Or just a wrapper? Etc. etc.: I’m still searching for some of overall guide/howto…
Agreed. But If I start a VM, using this pool, only when the pool (finally) is available, where is the problem? If I add a volatile virtual disk to a vm, it works fine, although volatile. But if I start the VM after a reboot, volatile disk available and pool “started”, I’m getting this “access rights” error. Although virt-manager started with sudo … confusing…
Not an option for me, as this usb3 hdd really is only on demand. I’ve a slow but completely noiseless zotac zbox-c, only ssd, no cpu fan, …, and I can stand spinning disks only if really needed
Seriously: hdd is for backups, and for testing vms, only. Really not permanently mounted needed.
That’s an idea, I’ll play a little with symbolic links…
Libvirt is a kind of universal virtualization manager with both graphical apps (vm manager, virt install) and command line (virsh).
Although openSUSE will configure libvirt to manage KVM, Xen and LXC by default, libvirt is not limited to these and can manage other virtualization.
If you’re very new to virtualization, KVM or Xen on openSUSE is a bit steeper learning curve because setups are normally more applicable to Enterprise use, ie
Guests might start on boot
Special storage configuration requirements like Storage Pools
Less intuitive application workflows (It’s helpful to know what you’re doing or what you should be looking for)
More friendly virtualization technologies include Virtualbox and VMware Player.
Both of these generally assume that you will manually launch your Guests as needed instead of automatically starting.
Virtualbox in particular installs almost entirely as a User mode application with flexible permissions.
User tools like Virtual Machine management is friendlier, and more attention is applied to helping a less knowledgeable User.
Although directed to Users new to virtualization, Virtualbox and VMware Player aren’t necessarily lacking in functionality. You can create almost any virtual machine you’d likely want or need, and you can configure complex virtual networking between your virtual and physical machines. You can set up varied and detailed management policies, you can probably even run a small business using these technologies with some work.
So,
For instance your permissions problem wouldn’t exist in Virtualbox.
Simply re-configure your default location for your virtual machine files and it’ll likely “just work.”
And whatever you learn in any virtualization can generally be used to explore some other virtualization. Xen is the only one that’s pretty much its own, every other virtualization that uses a hypervisor will use pretty much the same terminology and practices although as expected each will have its own strengths and weaknesses.
Sorry for replying that late, I didn’t want to be impolite, was just very busy.
** THANK YOU VERY MUCH for your fantastic and very helpful overview! **
In fact I was using VMware Workstation in my job for a long time now, on MS-WIN, and as you said, all VMs always manually launched, on demand.
So as I’m using privately only Linux, I’ve started longer ago with VMware Player on OpenSuse, for some small private VMs. Was somewhat painful, as there was a VMware Player bug, specific on OpenSuse, a while ago, for a longer time. Preventing kernel modules to be compiled. Which was needed always for new kernels arriving via zypper. Fixed now by VMware, but I’ve decided to switch to a FOSS solution asap. And as I know that my VPS, also OpenSuse, is running based on kvm/qemu, I’ve decided to start with qemu at home.
Wanted to try Virtualbox also just recently, but another bug prevented me from even installing it. Also fixed in the meantime - the devil is in the details
Reason why I didn’t state is that I’m somewhat confused about the differentiation between libvirt(d), XEN, KVM, QEMU, and, got recommendations for, Virtualbox. Not sure what component is doing what, is virt_manager part of …? Or just a wrapper? Etc. etc.: I’m still searching for some of overall guide/howto…