[Solved] Help with Virt-Manager & QEMU-KVM

[pwzhangzz]

I usually create virtual machines on a usb stick. I have no problem with VirtualBox, but with virt-manager, the following error msg is received:

Unable to complete install: 'Cannot access storage file '/media/ryzen/extra0/kvm/debian12e.qcow2' (as uid:64055, gid:64055): Permission denied'

[pwzhangzz]

@pbear: Thanks, I got it solved. It is not straightforward. Since we are dealing almost exclusively with desktop users with very well defined vm needs, VirtualBox is really the way to go, especially now that its vboxsvga virtual graphics driver is even better than VMWare has to offer (a great testimony to the power of open-source, including the open-sourced in-kernel amdgpu driver). But thanks again for your endeavor; I will continue to watch this thread.

There is one suggestion from our experiences of using qemu/kvm vis-a-vis VirtualBox, in that when creating qemu/kvm guests, we always check the "unmap" box in ViirtIO disk bus, as shown in the following screenshot:

This way, deleted files from the vm will be automatically freed (unmapped) thus will not cause the vm to indefinitely expand. Again, since we only have very well defined needs for our (desktop) vms, if there is one thing that may entice me to go back to qemu/kvm, this is it.

[CwF]

Maybe leave this thread for promoting the default repository approach...

deleted files from the vm will be automatically freed (unmapped) thus will not cause the vm to indefinitely expand.

virt-sparsify takes care of that.

[pwzhangzz]

Maybe leave this thread for promoting the default repository approach...

Me bad

deleted files from the vm will be automatically freed (unmapped) thus will not cause the vm to indefinitely expand.

virt-sparsify takes care of that.

Thanks. Virt-sparsify is a batch operation (and there is an equivalent command in vbox); however, many of our clients actually prefer this approach and do not want deleted files instantly removed from the vm.

[pbear]

Starting with the original issue, I have several VirtMan VMs running from USB hard drive, so there's no structural impediment. OTOH, I did run into a similar message (may even have been identical) when trying to set up a quickie test on another computer using a USB flash drive. Main difference between the two cases was that the former is mounted (via fstab) at /data/vm-annex, while the latter was mounted at /media/pbear. Meanwhile, VirtMan was running as root (albeit with me as a member of the libvirt group). User-root unable to access a mount at /media/$USER is routine and has nothing to do with VirtMan. Could that have been your issue?

Don't understand the point about unmapping. VirtMan VHDs aren't dynamic, so there's nothing to expand (or contract). Do you have a reference handy?

Edit: A little research (all I have time for at the moment) suggests unmap was recommended at one time because virtio didn't yet support trim on SSDs. If that's what you're talking about, looks like it's no longer an issue.

[CwF]

I usually create virtual machines on a usb stick. I have no problem with VirtualBox, but with virt-manager, the following error msg is received:

Unable to complete install: 'Cannot access storage file '/media/ryzen/extra0/kvm/debian12e.qcow2' (as uid:64055, gid:64055): Permission denied'

You don't need to have the device mounted at all anywhere in the host, better off if it isn't, only 'enumerated' is needed

Code: Select all

# ln -s --target-directory=/var/lib/libvirt/images /dev/disk/by-one-of-choices

Also, this choice from the default storage pool then preferably uses virtio. Can be any of the emulated choices, non-shareable and 'raw'

Linking any storage or file into the default storage simplifies and bypasses user permission issues.

A more direct way is to vfio pass the usb port itself. This solution allows any real usb bootable device as if bios booted.

[pwzhangzz]

@pbear and @CwF:

What I did was re-mounted the target usb partition:

Code: Select all

sudo mount /dev/sda2 /home/ryzen/kvm

then created a new pool ("usb-c") and a new volume ("/home/ryzen/kvm/kvm/debian12e.qcow2") as shown in the following screenshot:

The workaround was very simple but not straightforward. Thanks a whole lot for spending time tending to this problem.

[pbear]

Excellent. For anyone else running into the issue, another option is mounting at /media/libvirt (or similar). Which is to say, it's specifically mounting to /media/<user> which restricts access, not mounting to /media in general. Some may prefer mounting to /media on consistency grounds, as it's the official mount area for removable drives. As mentioned, I don't worry about it. Another little trick. Although frowned on by some, the mount for a removable drive can be included in fstab. Just be sure to use the nofail parameter. Then, when the drive is attached, the system will use the mount point designated in fstab, i.e., no need to specify manually.