From: Richard Laager <rlaager@wiktel.com>
To: kvm@vger.kernel.org
Subject: [RFC] Consistent Snapshots Idea
Date: Mon, 21 Nov 2011 06:01:09 -0600 [thread overview]
Message-ID: <1321876869.761.59.camel@watermelon.coderich.net> (raw)
[-- Attachment #1: Type: text/plain, Size: 1737 bytes --]
I'm not an expert on the architecture of KVM, so perhaps this is a QEMU
question. If so, please let me know and I'll ask on a different list.
Background:
Assuming the block layer can make instantaneous snapshots of a guest's
disk (e.g. lvcreate -s), one can get "crash consistent" (i.e. as if the
guest crashed) snapshots. To get a "fully consistent" snapshot, you need
to shutdown the guest. For production VMs, this is obviously not ideal.
Idea:
What if KVM/QEMU was to fork() the guest and shutdown one copy?
KVM/QEMU would momentarily halt the execution of the guest and take a
writable, instantaneous snapshot of each block device. Then it would
fork(). The parent would resume execution as normal. The child would
redirect disk writes to the snapshot(s). The RAM should have
copy-on-write behavior as with any other fork()ed process. Other
resources like the network, display, sound, serial, etc. would simply be
disconnected/bit-bucketed. Finally, the child would resume guest
execution and send the guest an ACPI power button press event. This
would cause the guest OS to perform an orderly shutdown.
I believe this would provide consistent snapshots in the vast majority
of real-world scenarios in a guest OS and application-independent way.
Implementation Nits:
* A timeout on the child process would likely be a good idea.
* It'd probably be best to disconnect the network (i.e. tell the
guest the cable is unplugged) to avoid long timeouts. Likewise
for the hardware flow-control lines on the serial port.
* For correctness, fdatasync()ing or similar might be necessary
after halting execution and before creating the snapshots.
Richard
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
next reply other threads:[~2011-11-21 12:07 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-21 12:01 Richard Laager [this message]
2011-11-21 12:31 ` [RFC] Consistent Snapshots Idea Avi Kivity
2011-11-21 14:27 ` [Qemu-devel] " shu ming
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1321876869.761.59.camel@watermelon.coderich.net \
--to=rlaager@wiktel.com \
--cc=kvm@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).