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 . . . #-----------------------------------#
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