Bug 598175

Summary: virt-install does not check permissions for existing disk images
Product: [Community] Virtualization Tools Reporter: Michael S. Tsirkin <mst>
Component: virtinstAssignee: Cole Robinson <crobinso>
Status: CLOSED DUPLICATE QA Contact:
Severity: medium Docs Contact:
Priority: low    
Version: unspecifiedCC: berrange, dallan, dyuan, gsun, jbrier, jwu, kxiong, mzhan, pbenas, rjones, rwu, xen-maint, zpeng
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: 2012-02-07 22:29:51 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Michael S. Tsirkin 2010-05-31 16:40:08 UTC
Description of problem:

[root@virtlab16 mst]# virt-install --location http://download.devel.redhat.com/rel-eng/latest-RHEL6.0/6/Server/x86_64/os/ --name mst1 --ram 2000 --disk /home/mst/vmgr.qcow2,size=100


Starting install...
Retrieving file .treeinfo...                                                      | 3.2 kB     00:00 ... 
Retrieving file vmlinuz...                                                        | 7.3 MB     00:00 ... 
Retrieving file initrd.img...                                                     |  57 MB     00:06 ... 
Creating storage file vmgr.qcow2                                                  | 100 GB     00:00     
ERROR    internal error Process exited while reading console log output: char device redirected to /dev/pts/1
qemu: could not open disk image /home/mst/vmgr.qcow2: Permission denied

Domain installation does not appear to have been
 successful.  If it was, you can restart your domain
 by running 'virsh start mst1'; otherwise, please
 restart your installation.
ERROR    internal error Process exited while reading console log output: char device redirected to /dev/pts/1
qemu: could not open disk image /home/mst/vmgr.qcow2: Permission denied
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/1
qemu: could not open disk image /home/mst/vmgr.qcow2: Permission denied

# ls -l /home/mst/vmgr.qcow2
-rwxr-xr-x. 1 root root 107374182400 May 31 12:36 /home/mst/vmgr.qcow2



Version-Release number of selected component (if applicable):
virt-manager-0.8.4-3.el6.noarch

How reproducible:
always

Steps to Reproduce:
1. yum install virt-manager
2. yum install qemu-kvm
3. virt-install --location http://download.devel.redhat.com/rel-eng/latest-RHEL6.0/6/Server/x86_64/os/ --name mst1 --ram 2000 --disk /home/mst/vmgr.qcow2,size=100
 
(/home/mst is an existing directory)

Actual results:

disk is created but permissions are such that qemu can not access.
virt-install then exits with a traceback
same if run with --prompt

Expected results:
1. should give permissions such that install can proceed
2. when run with --prompt, should report error and ask user to fix


Additional info:

Comment 1 RHEL Program Management 2010-05-31 16:55:48 UTC
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for
inclusion.

Comment 2 Cole Robinson 2010-06-14 18:14:44 UTC
*** Bug 589912 has been marked as a duplicate of this bug. ***

Comment 3 RHEL Program Management 2010-07-15 14:07:04 UTC
This issue has been proposed when we are only considering blocker
issues in the current Red Hat Enterprise Linux release. It has
been denied for the current Red Hat Enterprise Linux release.

** If you would still like this issue considered for the current
release, ask your support representative to file as a blocker on
your behalf. Otherwise ask that it be considered for the next
Red Hat Enterprise Linux release. **

Comment 5 Suzanne Logcher 2011-03-28 21:08:49 UTC
Since RHEL 6.1 External Beta has begun, and this bug remains 
unresolved, it has been rejected as it is not proposed as an 
exception or blocker.

Red Hat invites you to ask your support representative to 
propose this request, if appropriate and relevant, in the 
next release of Red Hat Enterprise Linux.

Comment 10 Cole Robinson 2011-09-27 15:09:39 UTC
This is actually a fair bit of work as it requires auto-storageifying all specified disk paths in virt-install (registering the media as a libvirt storage pool). Not likely to be safe for 6.2 at this point, so deferring to 6.3

Comment 13 Cole Robinson 2011-12-09 23:46:58 UTC
While this would be useful for RHEL, it's a decent amount of work, and our capacity for virt-manager/virtinst changes is reduced for RHEL6.3. Moving to the upstream virtinst tracker.

Comment 14 Cole Robinson 2012-01-25 18:44:41 UTC
*** Bug 580482 has been marked as a duplicate of this bug. ***

Comment 15 Cole Robinson 2012-01-25 18:45:03 UTC
*** Bug 672585 has been marked as a duplicate of this bug. ***

Comment 16 Cole Robinson 2012-02-07 22:29:51 UTC
Duping to virt-manager bug for autopoolifying storage, which involves the same code, and will be the only certain way we can detect if there are permission errors.

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