Bug 530210

Summary: virt-manager setfacl() fails on filesystems not mounted with the 'acl' option
Product: [Fedora] Fedora Reporter: Michal Schmidt <mschmidt>
Component: python-virtinstAssignee: Cole Robinson <crobinso>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: high    
Version: rawhideCC: berrange, bobgus, crobinso, jforbes, jonathan.underwood, markmc, michael.monreal+bugs, virt-maint
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-12-03 18:47:48 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Bug Depends On:    
Bug Blocks: 498969    
Attachments:
Description Flags
Screenshot showing 'No hard-disk found!'
none
Screenshot after boot and login of client none

Description Michal Schmidt 2009-10-21 17:34:15 EDT
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.)
Comment 1 Cole Robinson 2009-10-22 08:51:08 EDT
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.
Comment 2 Michal Schmidt 2009-10-22 10:55:31 EDT
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.
Comment 3 Mark McLoughlin 2009-10-29 12:54:13 EDT
Michal: thanks for the explanation

Not sure what we can do here apart from have a useful error message for this case
Comment 4 Michael Monreal 2009-10-29 13:15:04 EDT
*** Bug 529957 has been marked as a duplicate of this bug. ***
Comment 5 Michael Monreal 2009-10-29 13:22:07 EDT
(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.
Comment 6 Bob Gustafson 2009-11-03 15:12:52 EST
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
Comment 7 Bob Gustafson 2009-11-03 15:17:50 EST
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..
Comment 8 Bob Gustafson 2009-11-03 15:36:19 EST
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 ~]#
Comment 9 Bob Gustafson 2009-11-03 16:27:39 EST
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.
Comment 10 Bob Gustafson 2009-11-03 16:32:23 EST
Created attachment 367362 [details]
Screenshot after boot and login of client
Comment 11 Bob Gustafson 2009-11-03 18:00:02 EST
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
Comment 12 Michal Schmidt 2009-11-04 02:17:14 EST
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.
Comment 13 Bob Gustafson 2009-11-04 09:24:56 EST
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.
Comment 14 Michal Schmidt 2009-11-04 10:18:49 EST
(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
Comment 15 Mark McLoughlin 2009-11-20 14:27:41 EST
*** Bug 539369 has been marked as a duplicate of this bug. ***
Comment 16 Bob Gustafson 2009-11-22 00:01:51 EST
(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.
Comment 17 Cole Robinson 2009-12-03 18:43:27 EST
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.
Comment 18 Cole Robinson 2009-12-03 18:47:48 EST
This should be fixed in python-virtinst-0.500.1-1.fc13 which will be in the next rawhide compose.