Virt-install can't find image behind symbolic link

1
votes

I ran into some strange behavior while setting up a script to start kvm instances today, and am hoping you all can weigh in what's going on here.

Setup: I have a script that starts a kvm with virt-install.

virt-install ... --disk=image.qcow2 ...

I want to run the same script on different versions of image.qcow2, so I created a symbolic link of a to my latest image.

My directory stucture would look something like this:

startKvm.sh
image.qcow2 -> image_v2.0.qcow2
image_v2.0.qcow2
image_v1.0.qcow2

However, when I tried to run my virt-install command, it returned the following error.

ERROR internal error: process exited while connecting to monitor: datetime qemu-kvm: -drive file=/path/image.qcow2,if=none,id=drive-ide0-0-0,format=qcow2: could not open disk image /path/image.qcow2: Could not open file: Permission denied

Thoughts on the cause and alternate solutions?

1
symlinkkvm
I don't know but there are many things that could go wrong. It's clearly about permissions but the solution is not immediate. You can try to change the permissions with chmod or the owner with chown. Or maybe you must be root and need to use sudo. There are even more possible solutions but it's impossible to guess what will help you. If you do ls -l *.qcow2 what permissions do you get? - pid
The files are owned by root and I ran as root. - Brittany
I don't really know but as far as I can tell this means that the first access is exclusive so the second cannot be performed. It's not really a problem of permissions but rather of exclusivity. This is how flocking works: flock. - pid

1 Answers

0
votes

I've had a similar idea to use symlinks, however in my scenario I run virt-manager via SSH with X forwarding as a user in wheel (admin) group. Creating a virtual guest produced same error:

Unable to complete install: 'internal error: process exited while connecting to monitor: 2018-02-24T07:53:19.064452Z qemu-kvm: -drive file=/var/lib/libvirt/images/archlinux-2018.02.01-x86_64.iso,format=raw,if=none,id=drive-ide0-0-1,readonly=on: could not open disk image /var/lib/libvirt/images/archlinux-2018.02.01-x86_64.iso: Could not open '/var/lib/libvirt/images/archlinux-2018.02.01-x86_64.iso': Permission denied'

Issue is, in fact, with permissions. When setting up an .iso image using qemu-kvm, it changes its ownership to user/group qemu upon deployment. We need to make sure user qemu has access rights throughout whole path to the file.

Test case

User running virt-manager: yahol (wheel/admin group)
Iso or qcow2 image location: /home/yahol/isos/archlinux-2018.02.01-x86_64.iso

Note: please ignore the timestamps as I've hacked together this answer over 2 days. It was late and I was too tired to finish it the previous day.

Starting with image in user's home directory:

$ ll /home/yahol/isos/archlinux-2018.02.01-x86_64.iso
$ -rw-r--r--. 1 yahol yahol 565182464 Feb 24 08:49 archlinux-2018.02.01-x86_64.iso

Creating symlink as root in default path to KVM images:

# cd /var/lib/libvirt/images
# ln -s /home/yahol/isos/archlinux-2018.02.01-x86_64.iso
lrwxrwxrwx. 1 root root 48 Feb 23 21:35 archlinux-2018.02.01-x86_64.iso -> /home/yahol/isos/archlinux-2018.02.01-x86_64.iso

Symlink belongs to user root, while actual file still has user/group of a regular user. Setting up and deploying virtual machine via virt-manager. Notice how user/group of image file changes to qemu:

$ ll /home/yahol/isos/archlinux-2018.02.01-x86_64.iso
-rw-r--r--. 1 qemu qemu 565182464 Feb 24 08:49 archlinux-2018.02.01-x86_64.iso

At this point VM manager, be it virt-manager or virt-install, throws the aforementioned error. This happens because user qemu doesn't have access to full path. Home dir of user yahol is only accessible to user yahol:

$ ll -d /home/yahol/
drwx------. 7 yahol yahol 258 Feb 24 08:37 /home/yahol/

Now let's create another path to which qemu has full access:

# mkdir -p /Qemu/Test/Iso
# mv archlinux-2018.02.01-x86_64.iso /Qemu/Test/Iso/
# chown -R qemu:qemu /Qemu/
# cd /var/lib/libvirt/images
# ln -s /Qemu/Test/Iso/archlinux-2018.02.01-x86_64.iso
# ll /Qemu/Test/Iso/archlinux-2018.02.01-x86_64.iso
-rw-rw-r--. 1 qemu qemu 565182464 Feb 23 08:53 /Qemu/Test/Iso/archlinux-2018.02.01-x86_64.iso
# ll /var/lib/libvirt/images
lrwxrwxrwx. 1 root root 46 Feb 24 09:39 archlinux-2018.02.01-x86_64.iso -> /Qemu/Test/Iso/archlinux-2018.02.01-x86_64.iso

This works perfectly fine, virtual machine has been deployed and it's running.

Possible solutions:

  • change ownership to entire path to actual image to user/group qemu

    # chown -R qemu:qemu /Qemu/

  • give read+execute permissions to others (world) to entire path to image

    # chmod -R o+rx /Qemu/

WARNING: This might have security implications!

  • create a directory owned by user/group qemu dedicated to iso images that will be symlinked

    # mkdir -p /Qemu/Test/Iso
# chown -R qemu:qemu /Qemu/

Summary:

Even though everything is done by user with root privileges, the actual user working with VM images is qemu. Adding qemu to wheel group would still require providing means to authenticate and, since it's a no-login user, it might be tricky.