This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 863695 - [F18] libguestfs fails to mount a disk image file(in this case qcow2) as 'root'
[F18] libguestfs fails to mount a disk image file(in this case qcow2) as 'root'
Status: CLOSED DEFERRED
Product: Virtualization Tools
Classification: Community
Component: libvirt (Show other bugs)
unspecified
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Libvirt Maintainers
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-10-06 13:07 EDT by Kashyap Chamarthy
Modified: 2016-04-26 10:48 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-03-23 18:55:41 EDT
Type: Bug
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 Kashyap Chamarthy 2012-10-06 13:07:32 EDT
Description of problem:

'guestfish' fails to mount a disk image as "root" on Fedora 18. Same disk image when opened as 'non-root', mounts just fine. 

[root@moon libvirt]# guestfish --ro -i -a /export/vmimgs2/f17-base.qcow2 
libguestfs: error: could not create appliance through libvirt: Unable to read from monitor: Connection reset by peer [code=38 domain=10]
[root@moon libvirt]# 


Version-Release number of selected component (if applicable):
------------------------------------------
[root@moon libvirt]# rpm -q libvirt libguestfs ; uname -r
libvirt-0.10.2-4.fc18.x86_64
libguestfs-1.19.45-1.fc18.x86_64
3.6.0-0.rc6.git0.2.fc18.x86_64
[root@moon libvirt]# 
------------------------------------------
[Note: the above version of libvirt is compiled latest libvirt(w/ a bump in spec-file, so that local rpms can upgrade smoothly) from git (as of 6-OCT-2012), and applied Eric's blockcommit patches.)

How reproducible:
All the time

Steps to Reproduce:

1/ Just have any disk image (in this case I used a qcow2)

2/ use guestfish to access the disk-image file directly in read only mode

# guestfish --ro -i -a /export/vmimgs2/f17-base.qcow2 

Actual results:

[root@moon libvirt]# guestfish --ro -i -a /export/vmimgs2/f17-base.qcow2                                                                            
libguestfs: error: could not create appliance through libvirt: Unable to read from monitor: Connection reset by peer [code=38 domain=10]


Expected results:

Disk image should be mounted just fine, irrespective of root

Additional info:

Mounts just fine as 'non-root'

#-----------------------------------#
[kashyap@moon qemu]$  guestfish --ro -i -a /export/vmimgs2/f17-base.qcow2 

Welcome to guestfish, the libguestfs filesystem interactive shell for
editing virtual machine filesystems.

Type: 'help' for help on commands
      'man' to read the manual
      'quit' to quit the shell

Operating system: Fedora release 17 (Beefy Miracle)
/dev/sda1 mounted on /

><fs> 
#-----------------------------------#
[root@moon libvirt]# getenforce 
Permissive
[root@moon libvirt]# 
#-----------------------------------#
[root@moon libvirt]# systemctl status libvirtd.service
libvirtd.service - Virtualization daemon
          Loaded: loaded (/usr/lib/systemd/system/libvirtd.service; disabled)
          Active: active (running) since Sat, 06 Oct 2012 22:10:49 +0530; 10min ago
        Main PID: 23344 (libvirtd)
          CGroup: name=systemd:/system/libvirtd.service
                  ├ 10756 /sbin/dnsmasq --strict-order --bind-interfaces --local=// --domain-needed --pid-file=/var/run/libvirt/network/default....
                  ├ 20158 /usr/bin/qemu-system-x86_64-oct6-git -name f17-base -S -M pc-1.2 -enable-kvm -m 2048 -smp 2,sockets=2,cores=1,threads=...
                  └ 23344 /usr/sbin/libvirtd
.
.
.
#-----------------------------------#
Comment 1 Cole Robinson 2016-03-23 18:55:41 EDT
Sorry for the lack of response.

When running libguestfs as root, it likely connects to qemu:///system, and qemu ends up running as user=qemu. Likely in this case the your regular had permissions to search/access the disk image, but the qemu user didn't have those permissions (maybe search access to a parent dir), so the mount would fail

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