Test suite: filesystem shares vs. snapshots
Originally created by Tails on #5571 (Redmine)
Filesystem shares cannot (due to QEMU limitations) be added to an active VM, and cannot (due to QEMU limitations) be active (i.e. mounted) during a snapshot save. Hence unmounting before save and remounting after restore them seems like a good idea.
However, the 9p* modules seem to get into a broken state during a save
- restore (the "tags" used as
mountsource cannot be found), so unloading before save and reload after restore comes to mind. But loading9pnet_virtiofails after a restore withprobe of virtio2 failed with error -2(indmesg) and the shares remain unmountable.
We should research this further, and determine whether we’re just doing something wrong, or if this is an upstream bug.
Given we don’t use 9p shares at all, do we care more than what’s needed to just quickly report this to Debian and be done with it?
Actually we do:
git grep "I setup a filesystem share". This bug is what forces us to "drop" the background snapshot in theMAT can clean a PDF filescenario. But it’s perhaps not a big issue. I’m fine with closing this bug and living with this as a limitation, I just want someone else’s oppinion. After all, we have more important stuff to do.
Feature Branch: test/5571-no-more-filesystem-shares