Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • T tails
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 971
    • Issues 971
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 27
    • Merge requests 27
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • tails
  • tails
  • Issues
  • #5571
Closed
Open
Issue created Jul 18, 2013 by import-from-Redmine@import-from-Redmine4 of 4 checklist items completed4/4 checklist items

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 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)
Edited May 21, 2020 by import-from-Redmine
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking