From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:38874) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UgxV8-0001Ke-Lh for qemu-devel@nongnu.org; Mon, 27 May 2013 09:30:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UgxV1-0000H0-E8 for qemu-devel@nongnu.org; Mon, 27 May 2013 09:30:14 -0400 Received: from mail03do.versatel.de ([89.245.129.23]:55409) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UgxV0-0000Cq-QC for qemu-devel@nongnu.org; Mon, 27 May 2013 09:30:07 -0400 Received: from i577b615c.versanet.de (HELO bonsai.wave) (m-starostik@versanet.de@[87.123.97.92]) (envelope-sender ) by mail03do.versatel.de (qmail-ldap-1.03) with ESMTPA for ; 27 May 2013 13:29:57 -0000 Received: from [195.145.12.228] (helo=cnu12512j2.localnet) by bonsai.wave with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1UgxUo-0002OO-Sy for qemu-devel@nongnu.org; Mon, 27 May 2013 15:29:54 +0200 From: Malte Starostik Date: Mon, 27 May 2013 15:29:52 +0200 Message-ID: <1413494.St6cfS7gEg@cnu12512j2> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="nextPart2084219.KWB5a20pl2" Content-Transfer-Encoding: 7Bit Subject: [Qemu-devel] virtfs fails after migration List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org This is a multi-part message in MIME format. --nextPart2084219.KWB5a20pl2 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Hello, trying to get migration work on a setup with several libvirt based hosts, I'm struggling with those VMs that use virtfs shares. I remember that in previous versions of qemu, the attempt to migrate those lead to chaos and mayhem, while now a *mounted* virtfs simply blocks migration. Fine so far, none of the virtfs shares we use need to be mounted all the time. However, when I unmount and then migrate (whether to a different host or just save/restore), the virtfs can't be mounted anymore. mount fails with "no such device", and in dmesg I get: 9pnet_virtio: no channels available The same thing applies to several combinations, the most up to date one is with host and guest both running a 3.8.13 kernel and qemu 1.4.0. qemu command line: /usr/bin/qemu-system-x86_64 -machine accel=kvm -name test01,process=qemu:test01 -S -M pc-1.2 -m 4096 -smp 1,sockets=1,cores=1,threads=1 -uuid 9d7f74e7-4a90-fbd1-796d- e23357931e80 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/test01.monitor,server,no wait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc - no-shutdown -kernel /var/lib/libvirt/images/boot/vmlinuz-3.8.13-gentoo - initrd /var/lib/libvirt/images/boot/initramfs-3.8.13-gentoo.img -append root=UUID=0ccbddca-dc76-4965-95cc-c16956d2670d quiet -device piix3- usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device virtio-serial-pci,id=virtio- serial0,bus=pci.0,addr=0x4 -drive file=/dev/vg- vms/test01,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 -fsdev local,security_model=passthrough,id=fsdev- fs0,path=/mnt/portage,readonly -device virtio-9p-pci,id=fs0,fsdev=fsdev- fs0,mount_tag=portage,bus=pci.0,addr=0x7 -netdev tap,fd=20,id=hostnet0,vhost=on,vhostfd=21 -device virtio-net- pci,netdev=hostnet0,id=net0,mac=52:54:00:2b:26:e1,bus=pci.0,addr=0x 3 -chardev pty,id=charserial0 -device isa- serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio- serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spic e.0 -spice port=5900,addr=127.0.0.1,disable-ticketing,seamless- migration=on -vga qxl -global qxl-vga.ram_size=67108864 -global qxl- vga.vram_size=67108864 -incoming fd:18 -device virtio-balloon- pci,id=balloon0,bus=pci.0,addr=0x6 Need to reboot the guest for it to work again. Removing the 9p and 9pnet-virtio modules won't do. Is there any known fix or workaround? Kind regards, Malte --nextPart2084219.KWB5a20pl2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="us-ascii"

Hel= lo,

 

try= ing to get migration work on a setup with several libvirt based hosts, = I'm struggling with those VMs that use virtfs shares.

I r= emember that in previous versions of qemu, the attempt to migrate those= lead to chaos and mayhem, while now a *mounted* virtfs simply blocks m= igration. Fine so far, none of the virtfs shares we use need to be mou= nted all the time. However, when I unmount and then migrate (whether t= o a different host or just save/restore), the virtfs can't be mounted a= nymore.

mou= nt fails with "no such device", and in dmesg I get:

 

9pn= et_virtio: no channels available

 

The= same thing applies to several combinations, the most up to date one is= with host and guest both running a 3.8.13 kernel and qemu 1.4.0.

 

qem= u command line:

 

/us= r/bin/qemu-system-x86_64 -machine accel=3Dkvm -name test01,process=3Dqe= mu:test01 -S -M pc-1.2 -m 4096 -smp 1,sockets=3D1,cores=3D1,threads=3D1= -uuid 9d7f74e7-4a90-fbd1-796d-e23357931e80 -no-user-config -nodefaults= -chardev socket,id=3Dcharmonitor,path=3D/var/lib/libvirt/qemu/test01.m= onitor,server,nowait -mon chardev=3Dcharmonitor,id=3Dmonitor,mode=3Dcon= trol -rtc base=3Dutc -no-shutdown -kernel /var/lib/libvirt/images/boot/= vmlinuz-3.8.13-gentoo -initrd /var/lib/libvirt/images/boot/initramfs-3.= 8.13-gentoo.img -append root=3DUUID=3D0ccbddca-dc76-4965-95cc-c16956d26= 70d quiet -device piix3-usb-uhci,id=3Dusb,bus=3Dpci.0,addr=3D0x1.0x2 -d= evice virtio-serial-pci,id=3Dvirtio-serial0,bus=3Dpci.0,addr=3D0x4 -dri= ve file=3D/dev/vg-vms/test01,if=3Dnone,id=3Ddrive-virtio-disk0,format=3D= raw -device virtio-blk-pci,scsi=3Doff,bus=3Dpci.0,addr=3D0x5,drive=3Ddr= ive-virtio-disk0,id=3Dvirtio-disk0,bootindex=3D1 -fsdev local,security_= model=3Dpassthrough,id=3Dfsdev-fs0,path=3D/mnt/portage,readonly -device= virtio-9p-pci,id=3Dfs0,fsdev=3Dfsdev-fs0,mount_tag=3Dportage,bus=3Dpci= .0,addr=3D0x7 -netdev tap,fd=3D20,id=3Dhostnet0,vhost=3Don,vhostfd=3D21= -device virtio-net-pci,netdev=3Dhostnet0,id=3Dnet0,mac=3D52:54:00:2b:2= 6:e1,bus=3Dpci.0,addr=3D0x3 -chardev pty,id=3Dcharserial0 -device isa-s= erial,chardev=3Dcharserial0,id=3Dserial0 -chardev spicevmc,id=3Dcharcha= nnel0,name=3Dvdagent -device virtserialport,bus=3Dvirtio-serial0.0,nr=3D= 1,chardev=3Dcharchannel0,id=3Dchannel0,name=3Dcom.redhat.spice.0 -spice= port=3D5900,addr=3D127.0.0.1,disable-ticketing,seamless-migration=3Don= -vga qxl -global qxl-vga.ram_size=3D67108864 -global qxl-vga.vram_size= =3D67108864 -incoming fd:18 -device virtio-balloon-pci,id=3Dballoon0,bu= s=3Dpci.0,addr=3D0x6

 

Nee= d to reboot the guest for it to work again. Removing the 9p and 9pnet-= virtio modules won't do. Is there any known fix or workaround?

 

Kin= d regards,

Mal= te

--nextPart2084219.KWB5a20pl2--