Dear Maintainer,

   * What led up to the situation?
	  I added a virtio-9P filesystem device to an existing VM which then fails to initialize.
   * What exactly did you do (or not do) that was effective (or
     ineffective)?
	  I used virtual machine manager to add the device with the VM powered off. Removing the device avoids the problem.

The virtual machine manager reports the following error in an error dialog:

Error starting domain: internal error: early end of file from monitor: possible problem:
qemu-system-x86_64: -device virtio-9p-pci,id=fs0,fsdev=fsdev-fs0,mount_tag=pwk,bus=pci.0,addr=0x7: Virtio-9p Failed to initialize fs-driver with id:fsdev-fs0 and export path:/home/stevie/Documents/PWK
qemu-system-x86_64: -device virtio-9p-pci,id=fs0,fsdev=fsdev-fs0,mount_tag=pwk,bus=pci.0,addr=0x7: Device initialization failed.
qemu-system-x86_64: -device virtio-9p-pci,id=fs0,fsdev=fsdev-fs0,mount_tag=pwk,bus=pci.0,addr=0x7: Device 'virtio-9p-pci' could not be initialized

Can you please advise? I'd like to use a passthrough file system with my Linux VMs.

Regards

Steve

24.08.2014 07:09, stevie wrote:

Please show the properties of fsdev-fs0 device too (corresponding part of the qemu command line).
Without that, it is impossible to tell what is going on.

Thanks,

/mjt

24.08.2014 07:09, stevie wrote:

Please show the properties of fsdev-fs0 device too (corresponding part of the qemu command line).
Without that, it is impossible to tell what is going on.

Thanks,

/mjt

I've configured various Filesystem devices using the Virtual Machine
Manager but, when such a device is present, the VMM fails to initialize
and the VM does not launch.

I instrumented the Virtual Machine Manager's qemu-system-x86_64 command
invocation to dump its command line flags. Here is an example of the
command line for a failing configuration:

usr/bin/qemu-system-x86_64 -enable-kvm -name Kali-Kaos -S -machine
pc-i440fx-2.1,accel=kvm,usb=off -m 1024 -realtime mlock=off -smp
1,sockets=1,cores=1,threads=1 -uuid 2613b593-b199-fd2a-1674-c2a32848d1fd
-no-user-config -nodefaults -chardev
socket,id=charmonitor,path=/var/lib/libvirt/qemu/Kali-Kaos.monitor,server,nowait
-mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc
-no-shutdown -boot strict=on -device
piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive
file=/var/lib/libvirt/images/Kali-Kaos.img,if=none,id=drive-virtio-disk0,format=raw
-device
virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1
-drive if=none,id=drive-ide0-1-0,readonly=on,format=raw -device
ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -fsdev
local,security_model=passthrough,id=fsdev-fs0,path=/home/stevie/Documents/PWK
-device
virtio-9p-pci,id=fs0,fsdev=fsdev-fs0,mount_tag=pwk,bus=pci.0,addr=0x7
-netdev tap,fd=24,id=hostnet0,vhost=on,vhostfd=25 -device
virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:fc:38:21,bus=pci.0,addr=0x3
-chardev pty,id=charserial0 -device
isa-serial,chardev=charserial0,id=serial0 -device usb-tablet,id=input0
-vnc 127.0.0.1:1 -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -device
intel-hda,id=sound0,bus=pci.0,addr=0x4 -device
hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device
virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6

Hope this helps :)

Okay. I see where the problem is.

The problem is that qemu does not report actual errors returned by the
system - in this case, to statfs() syscall which it uses when initing
the local filesystem.  So there's no way to know what problem it had
when it is unable to initialize 9pfs.

In your case it is either "Permission denied" or "No such file or
directory", referring to path /home/stevie/Documents/PWK.  Since
you already instrumented your qemu to print the actual command
line, you can run it with strace and see which syscall fails and
in which way right before it reports the error (the only syscall
in this context is statfs()).

I'm retitling and remarking this bugreport, making it a wishlist
for qemu to report actual errors during init of 9pfs, which is
what it actually about.  I'll ping upstream about this.

Thanks,

/mjt