Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Corrupted backup/clone of running VMs that are stored in a 'file' driver pool #4324

Closed
rustybird opened this issue Sep 20, 2018 · 4 comments · Fixed by QubesOS/qubes-core-admin#375
Assignees
Labels
C: core diagnosed Technical diagnosis has been performed (see issue comments). P: critical Priority: critical. Between "major" and "blocker" in severity. r4.1-dom0-stable

Comments

@rustybird
Copy link

rustybird commented Sep 20, 2018

Qubes OS version:

R4.0

Affected component(s):

qubes-core-dom0

General notes:

I just realized the significance of a comment in qubes-core-admin/qubes/storage/file.py:

def export(self):
    # FIXME: this should rather return snapshot(self.path, self.path_cow)
    #  if domain is running
    return self.path

So a backup or clone from any running VM stored in a file driver pool currently operates on the live data. If it is modified while the copy is in progress, that would probably result in silent data corruption, possibly on the VM filesystem level.

@andrewdavidwong andrewdavidwong added bug C: core P: critical Priority: critical. Between "major" and "blocker" in severity. labels Sep 21, 2018
@andrewdavidwong andrewdavidwong added this to the Release 4.0 updates milestone Sep 21, 2018
@tasket
Copy link

tasket commented Sep 21, 2018

Not sure if this is an option with Xen...

Wouldn't opening the image files with an exclusive lock resolve this issue? Side effect would be that backing up, cloning, etc. would require the VMs to be in a stopped state.

@rustybird
Copy link
Author

Not sure if this is an option with Xen...

Wouldn't opening the image files with an exclusive lock resolve this issue?

It's almost tempting, in a perverse way, to somehow try and shoehorn mandatory file locks into the block-snapshot script... Advisory locks could work though. Then it would be up to the consumers of export() to implement the other side of the lock.

And/or get it over with and start deprecating the file driver in R4.1. Like, no varlibqubes pool at all for non-FICLONE root filesystems, and a big fat warning whenever the user attempts to create any other file pool.

@qubesos-bot
Copy link

Automated announcement from builder-github

The package qubes-core-dom0-4.1.17-1.fc32 has been pushed to the r4.1 testing repository for dom0.
To test this update, please install it with the following command:

sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing

Changes included in this update

@qubesos-bot
Copy link

Automated announcement from builder-github

The package qubes-core-dom0-4.1.17-1.fc32 has been pushed to the r4.1 stable repository for dom0.
To install this update, please use the standard update command:

sudo qubes-dom0-update

Or update dom0 via Qubes Manager.

Changes included in this update

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C: core diagnosed Technical diagnosis has been performed (see issue comments). P: critical Priority: critical. Between "major" and "blocker" in severity. r4.1-dom0-stable
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants