libvirt users - May 2015 - 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!

Gentle ping, ~6 weeks later. :)

On 05/16/2015 08:08 PM, anonym wrote:
> [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!