Bug 598175 - virt-install does not check permissions for existing disk images
Summary: virt-install does not check permissions for existing disk images
Keywords:
Status: CLOSED DUPLICATE of bug 557107
Alias: None
Product: Virtualization Tools
Classification: Community
Component: virtinst
Version: unspecified
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Cole Robinson
QA Contact:
URL:
Whiteboard:
: 580482 589912 672585 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-05-31 16:40 UTC by Michael S. Tsirkin
Modified: 2018-11-14 11:43 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-02-07 22:29:51 UTC
Embargoed:


Attachments (Terms of Use)

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 ***


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