Test suite: filesystem shares vs. snapshots

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 mount source cannot be found), so unloading before save and reload after restore comes to mind. But loading 9pnet_virtio fails after a restore with probe of virtio2 failed with error -2 (in dmesg) 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 the MAT can clean a PDF file scenario. 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

Attachments

• qemu_2.1_dfsg-12_deb8u2-with-p9-live-migration.patch

Subtasks

• #6224 (closed)
• #6225 (closed)
• #6226 (closed)
• #10214 (closed)

Original created by @tails on 5571 (Redmine)