Hide Forgot
I cannot start a previously-existing VM configuration due to an error when trying to access any disk image I configure: Traceback (most recent call last): File "/usr/share/virt-manager/virtManager/engine.py", line 567, in run_domain vm.startup() File "/usr/share/virt-manager/virtManager/domain.py", line 652, in startup self.vm.create() File "/usr/lib64/python2.6/site-packages/libvirt.py", line 293, in create if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self) libvirtError: internal error unable to start guest: qemu: could not open disk image /home/adamw/Download/desktop-x86_64-20090811.17.iso This happens for the 'hard disk' image in the same VM, if I leave it enabled, too. The file in question has these permissions: [adamw@adam Download]$ ls desktop-x86_64-20090811.17.iso -l -rw-rw-r--. 1 qemu qemu 740294656 2009-08-11 13:54 desktop-x86_64-20090811.17.iso and is configured as the VM's CD/DVD drive. I have tried with SELinux disabled, makes no difference. This may be the same as 517308, but my traceback is different in the earlier stages. I'm using libvirt-0.7.0-4 now, but saw the same behaviour with the previous version too.
Can you check the permissions on /home/adamw and /home/adanw/Download to make sure both directories have at least '--x' on them to allow 'qemu' user to access files Also if you have SELinux enforcing mode, do you get an AVCs ?
ah, you're right, that's probably the problem. ... confirmed. OTOH, this strikes me as a significant usability problem. 'Download an ISO and create a VM to boot from it' is a pretty reasonable use case, and mostly people will download to their home directory. I suspect an awful lot of people would run into this problem if some kind of fix isn't implemented. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Yeah its kind of annoying that /home/$USER defaults to mode 0700 instead of 0711. Having libvirt automatically change individual files permissions is semi-reasonable, but I wouldn't want to make libvirt change home directory permissions too. I think it really requires some confirmation from the user before doing that kind of thing. Perhaps virt-manager should explicitly watch for case where a user selects a location under $HOME, and then warn the user if their home directory, or an intermediate directory path has overly restricted permissions, offerring to fix.
I guess I'm just not entirely convinced about the 'run qemu as qemu' thing. I ran virt-manager as adamw, I kinda am expecting it to work as if I'm running as me...if running as qemu introduces this kind of inconvenience I'm not sure it's a great idea. But you probably have a better overview than me :) -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
It is a very important security feature. If QEMU runs as root, and there is a flaw in QEMU there is a very high chance it can be used to compromise the entire host. There have been many flaws in QEMU so this is well worth it and this would have limited the impact of several of them.
couldn't qemu launch as the user who ran virt-manager in the first place? -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
It already does that if you connect to qemu:///session URIs. virt-manager uses qemu:///system URI by default though, since that's the only way you get useful network connectivity.
Hmm. Okay. It just bugs me from a 'I'm a dumb user and know nothing about the technology' viewpoint; comparing it to the VMware or VirtualBox user experience, where I can run the app as a user and create a virtual machine in clicky-clicky fashion with the whole experience run as that user. I know I'm probably setting an unrealistic target by comparing the user experience with no regard to the underlying technology, but that's the angle I'm coming at it from :) -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
"Perhaps virt-manager should explicitly watch for case where a user selects a location under $HOME, and then warn the user if their home directory, or an intermediate directory path has overly restricted permissions, offerring to fix." strikes me as a pretty reasonable solution, regardless of which user qemu is running as.
This is a pretty serious usability issue, since it's a common use case to have people creating virtual machines in disks contained in their own home directories, and even though the workaround is fairly simple (chmod 'o+x' /home/dir), there's no need to make the user to loose time trying to figure out what's wrong. The error one will see is along the lines: Unable to complete install '<class 'libvirt.libvirtError'> internal error unable to start guest: qemu: could not open disk image /home/f12/Virt/images/opensolaris.img Traceback (most recent call last): File "/usr/share/virt-manager/virtManager/create.py", line 1489, in do_install dom = guest.start_install(False, meter = meter) File "/usr/lib/python2.6/site-packages/virtinst/Guest.py", line 628, in start_install return self._do_install(consolecb, meter, removeOld, wait) File "/usr/lib/python2.6/site-packages/virtinst/Guest.py", line 726, in _do_install self.domain = self.conn.createLinux(install_xml, 0) File "/usr/lib/python2.6/site-packages/libvirt.py", line 1077, in createLinux if ret is None:raise libvirtError('virDomainCreateLinux() failed', conn=self) libvirtError: internal error unable to start guest: qemu: could not open disk image /home/f12/Virt/images/opensolaris.img A user will think: Hey, this is on my home dir, how can I possibly not have access to this file? I created it myself with virt-manager?!?, so we shouldn't waste the user's time trying to figure out what's wrong (he probably has no idea that qemu is running under the qemu user). It was pointed out that the proper solution for this issue would be to have good network support for qemu:///session, and therefore make qemu:///session the default for the desktop user. However, I don't think that's doable by F12 timeframe. So the solution pointed out by comment #9 would be the way to go for F12, IMHO, so I'd like to hear Cole Robinson opinions on that.
(In reply to comment #10) > This is a pretty serious usability issue I agree. Moving to F12VirtBlocker
See also bug #524033 and bug #523960
*** Bug 524086 has been marked as a duplicate of this bug. ***
(In reply to comment #10) > This is a pretty serious usability issue, Yes, this certainly sucks. I should have tried to coordinate changes in the tools to match the libvirt change. > The error one will see is along the lines: > > Unable to complete install '<class 'libvirt.libvirtError'> internal error > unable to start guest: qemu: could not open disk image > /home/f12/Virt/images/opensolaris.img > This is part of the problem: it would be helpful if qemu could at least print strerror output here (and for opening kernel/initrd). I filed this as bz 524695. > > So the solution pointed out by comment #9 would be the way to go for F12, IMHO. Agreed, I'm working on this now.
This should be addressed in virt-manager-0.8.0-5. When attaching any storage to a guest (via 'New VM' or 'Add Hardware') we will attempt to verify that the 'qemu' user has search access. If not, we warn the user and offer to fix, using ACLs. The user can opt out, and optionally 'Never ask about this path again" if we have any false positives. Testing appreciated.
Looks fixed as of virt-manager-0.8.0-5.fc12.noarch.
Thanks for confirming.
Regressed in F13 (virt-manager 0.8.3/0.8.4)? Trying to boot from ISOs inside my home does *not* warn me of missing permissions and just gave an error on boot. After 'setfacl -m u:qemu:x /home/`whoami`' the problem is gone.
re-opening, then. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '13'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 13's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 13 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Anyone noticed the status of this lately? I haven't really.
AFAIK, this is fixed as of Fedora 15 (Actually it was fixed long before that, maybe F13 or F14).
Yeah I thought there were corner cases still lurking but I think they've all been shaken out. Closing
hey, I just found another. [adamw@vaioz Downloads]$ mount | grep /share/data systemd-1 on /share/data type autofs (rw,relatime,fd=23,pgrp=1,timeout=300,minproto=5,maxproto=5,direct) //192.168.1.13/Volume_1 on /share/data type cifs (rw,nosuid,relatime,sec=ntlm,unc=\\192.168.1.13\Volume_1,username=guest,uid=0,noforceuid,gid=0,noforcegid,addr=192.168.1.13,unix,posixpaths,serverino,acl,rsize=8192,wsize=8192,actimeo=1) [adamw@vaioz Downloads]$ ls -l /share/data/roms/Fedora-16-Alpha-x86_64-Live-Desktop.iso -rwxrwxrwx. 1 adamw adamw 613416960 Aug 9 12:03 /share/data/roms/Fedora-16-Alpha-x86_64-Live-Desktop.iso (try to boot a virtual machine with that .iso file as the CD drive) Error starting domain: unable to set user and group to '107:107' on '/share/data/roms/Fedora-16-Alpha-x86_64-Live-Desktop.iso': Invalid argument Traceback (most recent call last): File "/usr/share/virt-manager/virtManager/asyncjob.py", line 45, in cb_wrapper callback(asyncjob, *args, **kwargs) File "/usr/share/virt-manager/virtManager/engine.py", line 959, in asyncfunc vm.startup() File "/usr/share/virt-manager/virtManager/domain.py", line 1128, in startup self._backend.create() File "/usr/lib64/python2.7/site-packages/libvirt.py", line 330, in create if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self) libvirtError: unable to set user and group to '107:107' on '/share/data/roms/Fedora-16-Alpha-x86_64-Live-Desktop.iso': Invalid argument Well, yeah, it can't change the ownership of the file - it's on a CIFS share. But it has all the rights it could possibly need to the ISO. Shouldn't it be able to work *without* changing the file's ownership? -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
*** This bug has been marked as a duplicate of bug 527736 ***