Description of problem: If I run virt-manager as a non-root user and let it get privileges using PolicyKit, virt-manager is not able to create new KVM Fedora guests using network install. virt-manager works fine when run under root. Version-Release number of selected component (if applicable): python-virtinst-0.500.0-5.fc12.noarch libvirt-0.7.1-13.fc12.x86_64 qemu-0.11.0-7.fc12.x86_64 kernel-2.6.31.4-88.fc12.x86_64 How reproducible: always Steps to Reproduce: 1. Start virt-manager under an unprivileged user. 2. Connect to localhost(QEMU). 3. When PolicyKit agent asks for the root password for the "org.libvirt.unix.manage" action, provide it. 4. Go through the "Create a new virtual machine" wizard to create a F11 KVM x86_64 guest, install from network (HTTP, use any of the standard mirrors). Actual results: virt-manager retrieves vmlinuz and initrd, then just when it's about the start the virtual machine, it crashes with: Unable to complete install '<class 'libvirt.libvirtError'> internal error unable to start guest: char device redirected to /dev/pts/3 qemu: could not load kernel '/home/michich/.virtinst/boot/virtinst-vmlinuz.8vRxXF': Permission denied Traceback (most recent call last): File "/usr/share/virt-manager/virtManager/create.py", line 1575, 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/lib64/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: char device redirected to /dev/pts/3 qemu: could not load kernel '/home/michich/.virtinst/boot/virtinst-vmlinuz.8vRxXF': Permission denied ' Expected results: virt-manager retrieves vmlinuz and initrd, then proceeds with creating the VM successfully. Additional info: The "qemu" user obviously cannot access the vmlinuz under /home/michich, because my $HOME dir has 700 permissions. Should virt-install have put it in /var/lib/libvirt/boot instead? (It does that when it runs under root, and that's why it works that way.)
Can you attach ~/.virt-manager/virt-manager.log? The reason we don't put the kernel under /var/lib/libvirt/boot as a regular user is because we don't have proper permissions to do so. virt-manager should be trying to fix these permissions behind the scenes though, so something must be failing.
Ah, ~/.virt-manager/virt-manager.log is indeed enlightening: [Thu, 22 Oct 2009 15:05:49 virt-manager 19382] DEBUG (VirtualDisk:254) Cmd '['setfacl', '--modify', 'user:qemu:x', '/home/michich']' output: out=, err=setfacl: /home/michich: Operation not supported Turns out my /home is mounted without the "acl" option. I wonder why, because it's listed in /etc/fstab with "defaults"... OK, tune2fs -l $THE_VOLUME told me: Default mount options: (none) I originally created the filesystem by hand, using mkfs.ext4. So I guess the reason it usually works for people could be that maybe Anaconda puts "acl" into the default mount options when it creates filesystems. So the only bug in virt-manager is that the error message could be made more obvious in this case.
Michal: thanks for the explanation Not sure what we can do here apart from have a useful error message for this case
*** Bug 529957 has been marked as a duplicate of this bug. ***
(In reply to comment #2) > So I guess the > reason it usually works for people could be that maybe Anaconda puts "acl" into > the default mount options when it creates filesystems. I did not create my current /home when reinstalling the system for F12beta so I cannot speak for filesystems created from anaconda, but just adding my old /home in anaconda left me with just "defaults" in fstab (which seems to include "noacl"). Would be nice if virt-manager would check if ACLs are supported and not offer to do use this feature if not supported.
Created attachment 367352 [details] Screenshot showing 'No hard-disk found!' Screenshot showing 'No hard-disk found!' Hmm, wish I could go back to my 'comment' page to see what comment number this should go to. Maybe Comment #4
Hmm, I lost my whole bug report. Moral of the story - don't submit an attachment before doing a 'submit' on the comment. Will try to recreate..
I went into System->Services and restarted my libvirtd daemon so that it would be for sure under the correct security context. I am running Fedora 12 Beta on a machine which has hardware support for kvm. I went through the Virtual Machine Manager dialogs and created an image file: [root@hoho6 user1]# ls -Z /var/lib/libvirt/images -rw-------. qemu qemu system_u:object_r:svirt_image_t:s0:c80,c493 v1_t280.img [root@hoho6 user1]# tune2fs -l /var/lib/libvirt/images/v1_t280.img tune2fs 1.41.9 (22-Aug-2009) tune2fs: Bad magic number in super-block while trying to open /var/lib/libvirt/images/v1_t280.img Couldn't find valid filesystem superblock. [root@hoho6 user1]# This is probably as expected - a blank disk, ready to be written on by the install disk waiting in my cdrom drive. Going further, I got the screen (Comment #6) showing that the install disk could not find my hard disk. ------ Before I saw this bug report, I had been attempting to install using the command line: virt-install --prompt Using this command line and trial and error, I (once) got it to work and the install image saw the hard disk and I was able to partition it and partially install my guest system. I had chosen too small a disk volume and it did not fit (2G). Subsequent trial and error was not successful. I also tried with a command line: [root@hoho6 ~]# cat v1.sh virt-install -n v1_t280 -r 2000 --hvm \ --disk path=/root/v1_t280_disk,size=20 \ --cdrom=/root/t280_cd1.iso [root@hoho6 ~]# which was equally unsuccessful. --- Some additional comments --- The Virtual Machine Manager launches a dialog asking for the root password, but it does not transfer focus to that dialog. The New VM dialog has a typo - 'systen' instead of 'system' There are several duplicate 'def createXML' procedures, two are adjacent [root@hoho6 ~]# grep -n createXML /usr/lib64/python2.6/site-packages/libvirt.py 826: def createXML(self, xmldesc, flags): 834: def createXMLFrom(self, xmldesc, clonevol, flags): 1081: def createXML(self, xmlDesc, flags): 1089: def createXML(self, xmlDesc, flags): [root@hoho6 ~]#
OK, success. Although I don't really know if I can repeat it. This is the command line sequence: [root@hoho6 ~]# virt-install --prompt What is the name of your virtual machine? v1_t280 How much RAM should be allocated (in megabytes)? 2000 What would you like to use as the disk (file path)? /var/lib/libvirt/images/v1_280.img How large would you like the disk (/var/lib/libvirt/images/v1_280.img) to be (in gigabytes)? 30 What is the install CD-ROM/ISO or URL? /dev/cdrom Starting install... Allocating 'v1_280.img' | 0 B 00:00 Creating domain... | 0 B 00:00 Guest installation complete... restarting guest. ---- After rebooting the virtual client, logging in as root (The ctrl-alt key pattern is very helpful to move the mouse/keyboard/focus from the virtual client. I only saw the clue dialog for this pattern once..) Attached is a screen dump of my running T2 client, with partitions shown.
Created attachment 367362 [details] Screenshot after boot and login of client
I think the trick(s) were to 1) run as root in a shell window 2) store the image file in the directory /var/lib/libvirt/images/ so that the image file will inherit the required permissions from the directory. Is this correct? ------ Additional comment --- My client OS is not in the dropdown menu of possible OS. What about having an 'Other' entry in that list. Does this choice of OS have any consequences? I chose Fedora 12 for my T2 OS
Bob, I do not understand the connection between your comments and the topic of this bug ("virt-manager setfacl() fails on filesystems not mounted with the 'acl' option"). Perhaps you wanted to file a completely new bugreport? And yes, the choice of the guest OS type has major consequences. If you choose the guest will be running Fedora 12, qemu will not emulate a classic disk controller, but a faster virtio device. If your guest OS does not support virtio, it will not see the disks. I am not familiar with T2 OS, but this is probably the case.
I was getting permission problems on my guest image file. It could have been ACL related. In any case, putting the image file into the /var/lib/libvirt/images directory solved my problem. It may be a temp fix for your bug too. T2 runs quite well as a guest masquerading as Fedora 12. Perhaps these nuggets of information should be in the documentation rather than bug reports.
(In reply to comment #13) > In any case, putting the image file into the /var/lib/libvirt/images > directory solved my problem. It may be a temp fix for your bug too. I should have explicitly said it in comment #2: My problem was solved by changing the mount options: tune2fs -o acl,user_xattr $my_home_logical_volume
*** Bug 539369 has been marked as a duplicate of this bug. ***
(In reply to comment #12) > Bob, > And yes, the choice of the guest OS type has major consequences. If you choose > the guest will be running Fedora 12, qemu will not emulate a classic disk > controller, but a faster virtio device. If your guest OS does not support > virtio, it will not see the disks. I am not familiar with T2 OS, but this is > probably the case. I think I was probably in error saying that I configured my system as Linux/Fedora 12. I blew away my Fedora12-beta system and installed the release version. When I reinstalled my virtual system, I set the system to Linux/Fedora12 and then attempted to install an .iso of my virtual client. Everything seemed to work fine, except that I could not really read from the disk image. It looked like I could create partitions and mount them, but then when I rebooted my virtual client, grub could not find what I had written. I then deleted the virtual client image file and re-installed - this time selecting Other/Generic for the image file. Everything then worked fine and I am now running a virtual client as I had before with Fedora12-beta. I can only conclude that I must not have configured my previous virtual guest as Linux/Fedora12.
I think this should be fixed upstream, since if setfacl fails, we try to fallback to adding basic chmod type search permissions. If that fails, there's nothing else we can do.
This should be fixed in python-virtinst-0.500.1-1.fc13 which will be in the next rawhide compose.