Bug #5571: Test suite: filesystem shares vs. snapshots
Reproduce the 9p reload bug with a recent kernel
see parent ticket.
#4 Updated by anonym over 4 years ago
This is what I get if I try to save a (ram-only) snapshot when a shared file system is mounted:
Call to virDomainSaveFlags failed: internal error: unable to execute QEMU command 'migrate': Migration is disabled when VirtFS export path '/home/tailstester/TailsToaster/shared_files' is mounted in the guest using mount_tag '/shared_files' (Libvirt::Error)
Clearly, that's explicitly not supported.
If I unmount the share and save the snapshot, there's no error. However when trying to
mount the share again after restoring, the
mount call hangs (and cannot be killed, even with
SIGKILL). It doesn't matter if I unload the
9p before saving the snapshot, and then reloading it after restoring;
mount still hangs. If I also unload/reload the
9pnet modules, then I get this in
[ 150.224902] 9pnet: Installing 9P2000 support [ 150.254786] virtio-pci 0000:00:08.0: irq 42 for MSI/MSI-X [ 150.254813] virtio-pci 0000:00:08.0: irq 43 for MSI/MSI-X [ 150.255025] virtio-pci 0000:00:08.0: irq 42 for MSI/MSI-X [ 150.255042] virtio-pci 0000:00:08.0: irq 43 for MSI/MSI-X [ 150.255200] 9pnet_virtio: probe of virtio3 failed with error -2 [ 150.281973] FS-Cache: Loaded [ 150.283145] 9p: Installing v9fs 9p2000 file system support [ 150.283153] FS-Cache: Netfs '9p' registered for caching [ 150.340384] 9pnet_virtio: no channels available
i.e. the same issue as before. Now the
mountcommand fails immediately with:
mount: No such file or directory
which refers to the source, i.e. the "tag" used for the filesystem share (not the target directory).