Re: [libvirt-users] Snapshots vs filesystem shares

[Please keep me Cc:ed since I'm not subscribed to the list!] Hi list, The tl;dr; is: with Libvirt/QEMU, should it be possible to mount a filesystem share (of type='mount') after restoring from a snapshot that was taken when the filesystem share wasn't mounted? It's pretty clear that Libvirt/QEMU (currently, at least) doesn't support taking snapshots of a live guest which has active filesystem shares (type='mount'). I get this error: Call to virDomainSaveFlags failed: internal error: unable to execute QEMU command 'migrate': Migration is disabled when VirtFS export path '${TARGET_PATH}' is mounted in the guest using mount_tag '$TAG' (Libvirt::Error) I have a use case where I very much would like this combination. It wouldn't be a problem if the filesystem shares would have to be temporarily unmounted while taking the snapshot, and mounted again after restoring it. However, while trying that, `mount` hangs when trying to mount a filesystem share again *after* restoring the snapshot (unmounting and remounting works perfectly before that, of course). Nothing is reported in syslog. I've also tried unloading combinations of the various 9p and virtio related modules (like 9p, 9pnet_virtio, 9pnet, virtio, etc) before taking the snapshot, and then reload them after restoring it, in hope of getting them into a sane state again (or whatever is the issue). But then I've seen errors like this in syslog: 9pnet: Installing 9P2000 support virtio-pci 0000:00:08.0: irq 42 for MSI/MSI-X virtio-pci 0000:00:08.0: irq 43 for MSI/MSI-X virtio-pci 0000:00:08.0: irq 42 for MSI/MSI-X virtio-pci 0000:00:08.0: irq 43 for MSI/MSI-X 9pnet_virtio: probe of virtio3 failed with error -2 FS-Cache: Loaded 9p: Installing v9fs 9p2000 file system support FS-Cache: Netfs '9p' registered for caching 9pnet_virtio: no channels available and `mount` complains that the source (tag) doesn't exist when trying to mount the filesystem share again. For the record, the mount command I always use is simply: mount -t 9p -o trans=virtio $TAG $TARGET_DIR I've tried setting `-o debug=0xfff` but I get no debug info at all. Is it expected behaviour that filesystem shares get into a broken state after restoring a snapshot? If it's of any relevance, here's some more context: * The host is running Debian Jessie with Linux 3.16.7-ckt9-3~deb8u1, Libvirt 1.2.9, QEMU 2.1. * The guest is Tails (https://tails.boum.org) which is Debian Wheezy with Linux 3.16.7-ckt9-3. I doubt it matters since I tested this ~two years ago, and got (IIRC) the exact same results. Cheers!