Description of problem: When shared directory is added to vm it refuses to boot and gives errors. It was configured as mapped. Version-Release number of selected component (if applicable): This happens with libvirt version in Fedora 21. Fedora 20 is ok. How reproducible: Easily Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Please provide: - sudo virsh dumpxml $vmname - /var/log/libvirt/qemu/$vmname.log
I tested all shared folder modes and they are broken with the same error. Its reproducible on all Fedora host systems I see.
What _is_ the error? You haven't provided it. Please list the info requested in comment #1
I can only post through a vm and because shared folders isn't functioning I can't move the logs you needs into it and post them from there. A Catch 22.
Removed the needinfo flag be mistake.
I got the logs in using an iso. Error Message: Error starting domain: internal error: early end of file from monitor: possible problem: 2014-12-15 qemu-system-x86_64: -device virtio-9p-pci,id=fs0,fsdev=fsdev-fs0,mount_tag=shared,bus=pci.0,addr=0x9: Virtio-9p Failed to initialize fs-driver with id:fsdev-fs0 and export path:/home/user/Documents/shared 2014-12-15 qemu-system-x86_64: -device virtio-9p-pci,id=fs0,fsdev=fsdev-fs0,mount_tag=shared,bus=pci.0,addr=0x9: Device initialization failed. 2014-12-15 qemu-system-x86_64: -device virtio-9p-pci,id=fs0,fsdev=fsdev-fs0,mount_tag=shared,bus=pci.0,addr=0x9: Device 'virtio-9p-pci' could not be initialized Traceback (most recent call last): File "/usr/share/virt-manager/virtManager/asyncjob.py", line 89, in cb_wrapper callback(asyncjob, *args, **kwargs) File "/usr/share/virt-manager/virtManager/asyncjob.py", line 125, in tmpcb callback(*args, **kwargs) File "/usr/share/virt-manager/virtManager/domain.py", line 1388, in startup self._backend.create() File "/usr/lib64/python2.7/site-packages/libvirt.py", line 999, in create if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self) libvirtError: internal error: early end of file from monitor: possible problem: 2014-12-15 qemu-system-x86_64: -device virtio-9p-pci,id=fs0,fsdev=fsdev-fs0,mount_tag=shared,bus=pci.0,addr=0x9: Virtio-9p Failed to initialize fs-driver with id:fsdev-fs0 and export path:/home/user/Documents/shared 2014-12-15 qemu-system-x86_64: -device virtio-9p-pci,id=fs0,fsdev=fsdev-fs0,mount_tag=shared,bus=pci.0,addr=0x9: Device initialization failed. 2014-12-15 qemu-system-x86_64: -device virtio-9p-pci,id=fs0,fsdev=fsdev-fs0,mount_tag=shared,bus=pci.0,addr=0x9: Device 'virtio-9p-pci' could not be initialized dumpxml: <domain type='kvm'> <name>Whonix-Workstation</name> <uuid>02c600a7-e7bb-4c70-966f-a81b0a06baee</uuid> <description>Do not change any settings if you do not understand the consequences! Learn more: https://www.whonix.org/wiki/KVM#XML_Settings</description> <memory unit='KiB'>1048576</memory> <currentMemory unit='KiB'>1048576</currentMemory> <vcpu placement='static'>1</vcpu> <os> <type arch='x86_64' machine='pc-i440fx-2.1'>hvm</type> <boot dev='hd'/> </os> <features> <acpi/> <apic eoi='on'/> <pae/> <hap/> </features> <clock offset='utc'> <timer name='rtc' tickpolicy='catchup' track='guest'/> <timer name='kvmclock' present='no'/> <timer name='pit' present='no'/> <timer name='hpet' present='no'/> </clock> <on_poweroff>destroy</on_poweroff> <on_reboot>restart</on_reboot> <on_crash>restart</on_crash> <pm> <suspend-to-mem enabled='no'/> <suspend-to-disk enabled='no'/> </pm> <devices> <emulator>/usr/bin/qemu-kvm</emulator> <disk type='file' device='disk'> <driver name='qemu' type='qcow2'/> <source file='/var/lib/libvirt/images/Whonix-Workstation.qcow2'/> <target dev='vda' bus='virtio'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/> </disk> <controller type='virtio-serial' index='0'> <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> </controller> <controller type='usb' index='0'> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/> </controller> <controller type='pci' index='0' model='pci-root'/> <filesystem type='mount' accessmode='mapped'> <source dir='/home/user/Documents/shared'/> <target dir='shared'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x09' function='0x0'/> </filesystem> <interface type='network'> <mac address='52:54:00:e4:d1:f4'/> <source network='Whonix'/> <model type='virtio'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface> <channel type='spicevmc'> <target type='virtio' name='com.redhat.spice.0'/> <address type='virtio-serial' controller='0' bus='0' port='1'/> </channel> <input type='tablet' bus='usb'/> <input type='mouse' bus='ps2'/> <input type='keyboard' bus='ps2'/> <graphics type='spice' autoport='yes'> <clipboard copypaste='no'/> <filetransfer enable='no'/> </graphics> <sound model='ich6'> <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> </sound> <video> <model type='qxl' ram='256000' vram='256000' heads='1'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> </video> <memballoon model='virtio'> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/> </memballoon> <rng model='virtio'> <backend model='random'>/dev/random</backend> <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/> </rng> </devices> </domain> guest.log: 2014-12-15 : starting up LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin QEMU_AUDIO_DRV=spice /usr/bin/qemu-kvm -name Whonix-Workstation -S -machine pc-i440fx-2.1,accel=kvm,usb=off -cpu qemu64,-kvmclock,+kvm_pv_eoi -m 1024 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid 02c600a7-e7bb-4c70-966f-a81b0a06baee -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/Whonix-Workstation.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,clock=vm,driftfix=slew -global kvm-pit.lost_tick_policy=discard -no-hpet -no-shutdown -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 -drive file=/var/lib/libvirt/images/Whonix-Workstation.qcow2,if=none,id=drive-virtio-disk0,format=qcow2 -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x6,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -fsdev local,security_model=mapped, id=fsdev-fs0,path=/home/user/Documents/shared -device virtio-9p-pci,id=fs0,fsdev=fsdev-fs0,mount_tag=shared,bus=pci.0,addr=0x9 -netdev tap,fd=24,id=hostnet0,vhost=on,vhostfd=25 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:e4:d1:f4,bus=pci.0,addr=0x3 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -device usb-tablet,id=input0 -spice port=5900,addr=127.0.0.1,disable-ticketing,disable-copy-paste,disable-agent-file-xfer,seamless-migration=on -device qxl-vga,id=video0,ram_size=262144000,vram_size=262144000,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=0x7 -object rng-random,id=rng0,filename=/dev/random -device virtio-rng-pci,rng=rng0,bus=pci.0,addr=0x8 -msg timestamp=on 2014-12-15 qemu-system-x86_64: -device virtio-9p-pci,id=fs0,fsdev=fsdev-fs0,mount_tag=shared,bus=pci.0,addr=0x9: Virtio-9p Failed to initialize fs-driver with id:fsdev-fs0 and export path:/home/user/Documents/shared 2014-12-15 qemu-system-x86_64: -device virtio-9p-pci,id=fs0,fsdev=fsdev-fs0,mount_tag=shared,bus=pci.0,addr=0x9: Device initialization failed. 2014-12-15 qemu-system-x86_64: -device virtio-9p-pci,id=fs0,fsdev=fsdev-fs0,mount_tag=shared,bus=pci.0,addr=0x9: Device 'virtio-9p-pci' could not be initialized 2014-12-15 : shutting down
I found a similar bug report filed by a Debian user for the same qemu version: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=759080 They never found what was wrong from the vague error message. Do I need to do any further diagnostics?
(In reply to snaper from comment #6) > I got the logs in using an iso. > > Error Message: > > Error starting domain: internal error: early end of file from monitor: This usually indicates a qemu bug. Switching the component over to qemu.
Yes it looks like a qemu bug. I found the follow up conversation on qemu mailinglist related to the bug report I linked to in my last post. Nothing useful but it could give a hint of whats wrong: https://lists.gnu.org/archive/html/qemu-devel/2014-08/msg04134.html
Can someone please follow up on this? Not having shared folders is really disruptive to my workflow. I'm wishing everyone CC'd here a Happy New Year.
> 2014-12-15 qemu-system-x86_64: -device virtio-9p-pci,id=fs0,fsdev=fsdev-fs0,mount_tag=shared,bus=pci.0,addr=0x9: Virtio-9p Failed to initialize fs-driver with id:fsdev-fs0 and export path:/home/user/Documents/shared My guess is that since the QEMU process is probably running under a qemu:qemu user/group account, it will not have permission to access /home/user/..... and this then causes QEMU to shutdown.
In past versions of qemu (before F21) attaching a folder on the host was ok and the vm could boot. The SELinux prompts only appeared when transferring stuff in and out of the folder. They stopped after configuring an exception in SELinux access rules. NB At the moment I have SELinux labels permanently configured to allow access to libvirt for this folder I am trying to add.
(In reply to snaper from comment #12) > At the moment I have SELinux labels permanently configured to allow access > to libvirt for this folder I am trying to add. It's not just selinux, the qemu:qemu user/group needs to be able to access that path as well. So that means global search permissions on every parent directory at least. I'd see if you can reproduce the error with a 777 directory in /tmp or something, to determine whether it's a permissions issue or if shared directories are entirely broken
This message is a reminder that Fedora 21 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 21. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '21'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 21 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.