Bug 612428 - [6.0] A kvm guest OS can't be installed to a partition.
[6.0] A kvm guest OS can't be installed to a partition.
Status: CLOSED DUPLICATE of bug 589662
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: libvirt (Show other bugs)
6.0
All Linux
medium Severity medium
: rc
: ---
Assigned To: Daniel Veillard
Virtualization Bugs
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-07-08 03:49 EDT by Mark Wu
Modified: 2010-07-08 06:03 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-07-08 06:03:25 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Mark Wu 2010-07-08 03:49:30 EDT
Description of problem:
kvm guest failed to be installed on a partition with EPERM

Version-Release number of selected component (if applicable):
kernel-2.6.32-37.el6.x86_64
libvirt-0.8.1-7.el6

How reproducible:
100%

Steps to Reproduce:
# virt-install --hvm --name=test --vcpus=1 --check-cpu --ram=1024 --file=/dev/sda3 --mac=02:17:42:2F:04:46 --vnc --vncport=5946 --cdrom=/root/RHEL6.0-Beta2-x86_64-DVD1.iso  --extra-args=utf8 --prompt --os-type=linux --os-variant=virtio26 --accelerate
  
Actual results:
Starting install...
ERROR    internal error Process exited while reading console log output: char device redirected to /dev/pts/2
qemu: could not open disk image /dev/sda3: Operation not permitted

Domain installation does not appear to have been
 successful.  If it was, you can restart your domain
 by running 'virsh start test'; otherwise, please
 restart your installation.
ERROR    internal error Process exited while reading console log output: char device redirected to /dev/pts/2
qemu: could not open disk image /dev/sda3: Operation not permitted
Traceback (most recent call last):
  File "/usr/sbin/virt-install", line 1054, in <module>
    main()
  File "/usr/sbin/virt-install", line 936, in main
    start_time, guest.start_install)
  File "/usr/sbin/virt-install", line 978, in do_install
    dom = install_func(conscb, progresscb, wait=(not wait))
  File "/usr/lib/python2.6/site-packages/virtinst/Guest.py", line 972, in start_install
    return self._do_install(consolecb, meter, removeOld, wait)
  File "/usr/lib/python2.6/site-packages/virtinst/Guest.py", line 1037, in _do_install
    "install")
  File "/usr/lib/python2.6/site-packages/virtinst/Guest.py", line 1008, in _create_guest
    dom = self.conn.createLinux(start_xml, 0)
  File "/usr/lib64/python2.6/site-packages/libvirt.py", line 1262, in createLinux
    if ret is None:raise libvirtError('virDomainCreateLinux() failed', conn=self)
libvirtError: internal error Process exited while reading console log output: char device redirected to /dev/pts/2
qemu: could not open disk image /dev/sda3: Operation not permitted


Expected results:
kvm guest can be installed on partition successfully.

Additional info:
 virt-manager also failed with EPERM.
 You can reproduce it on dori1.gsslab.nrt.redhat.com  root/redhat
Comment 2 Mark Wu 2010-07-08 04:02:54 EDT
Some info in strace: 

12185 setregid(107, 107)                = 0     
12185 setreuid(107, 107)                = 0     
...
12185 execve("/usr/libexec/qemu-kvm", ["/usr/libexec/qemu-kvm", "-S", "-M",
"rhel6.0.0", "-enable-kvm", "-m", "1024", "-smp",
"1,sockets=1,cores=1,threads=1", "-name", "test", "-uuid",
"60eb4a45-4469-f6ee-8ed2-c0a51a0b"..., "-nodefaults", "-chardev",
"socket,id=monitor,path=/var/lib/"..., ...], [/* 3 vars */]) = 0 
...
12185 stat("/dev/sda3", {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 3), ...}) = 0
12185 stat("/dev/sda3", {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 3), ...}) = 0
12185 open("/dev/sda3", O_RDONLY|O_DSYNC|O_CLOEXEC) = -1 EPERM (Operation not
permitted)
12185 write(2, "qemu: could not open disk image "..., 67) = 67

But even I added the use into "disk" group or changed the mode of /dev/sda3, it
still failed with EPERM.
Comment 3 Mark Wu 2010-07-08 04:17:18 EDT
Try to use systemtap to find the check in kernel which reported EPERM. It failed in __blkdev_get and passed all permission checks before that.
do_sys_open
  do_filp_open
    do_last
      nameidata_to_filp
        __dentry_open
            blkdev_open (f->f_op->open)
              __blkdev_get    --> return -1 

In function __blkdev_get, it might fail at disk->fops->open (should be sd_open), but I can't find more using systemtap.
Comment 4 Daniel Berrange 2010-07-08 06:03:25 EDT

*** This bug has been marked as a duplicate of bug 589662 ***

Note You need to log in before you can comment on or make changes to this bug.