[libvirt-users] Snapshots vs filesystem shares

anonym anonym at riseup.net
Sat May 16 18:08:10 UTC 2015


[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!



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvirt-users/attachments/20150516/b8ba5caa/attachment.sig>


More information about the libvirt-users mailing list