6:31 a.m.
Hello,
I am working on a script to automatically create live snapshots of running VMs using
qemu-kvm 1.4.0 and libvirt 1.0.2. If a VM has multiple disks, I'd like to back them up
individually with separate calls to snapshot-create-as, so I can more easily manage the
disk images. The code I have now is essentially as follows:
virsh snapshot-create-as --domain "vmname" --name "snapshotname"
--description "snapshot description" --disk-only --atomic --no-metadata
--diskspec "vda"
I run this command for each block device (e.g vda, vdb, etc). However, after running the
above command (to only backup vda), I see that a snapshot has also been created for vdb. I
tried running it with --print-xml, which gives this output:
<domainsnapshot>
<name>05-22-14_17-09-25</name>
<description>05-22-14_17-09-25</description>
<disks>
<disk name='vda'/>
</disks>
</domainsnapshot>
What am I doing wrong - how can I tell snapshot-create-as to create an external snapshot
for a specific block device only (not all block devices)?
Also, while looking at the manpage, does the --live option do anything different if used
with the above command?
Thanks,
Andrew Martin
6:44 a.m.
On 05/22/2014 04:31 PM, Andrew Martin wrote:
Hello,
[Can you convince your mailer to wrap long lines?]
I am working on a script to automatically create live snapshots of
running VMs using qemu-kvm 1.4.0 and libvirt 1.0.2. If a VM has
Any reason you aren't upgrading to newer versions? Although these seem
sufficient for what you are trying.
multiple disks, I'd like to back them up individually with
separate
calls to snapshot-create-as, so I can more easily manage the disk
images. The code I have now is essentially as follows:
virsh snapshot-create-as --domain "vmname" --name
"snapshotname" --description "snapshot description" --disk-only
--atomic --no-metadata --diskspec "vda"
I run this command for each block device (e.g vda, vdb, etc). However, after running the
above command (to only backup vda), I see that a snapshot has also been created for vdb. I
tried running it with --print-xml, which gives this output:
<domainsnapshot>
<name>05-22-14_17-09-25</name>
<description>05-22-14_17-09-25</description>
<disks>
<disk name='vda'/>
</disks>
The problem you are facing is that the snapshot code MUST have an action
for every disk; and if you don't specify the action directly in your
<domainsnapshot> xml, then the action chosen is inherited from the
<domain> xml (if you used <disk snapshot='no'>) or ultimately from
the
type of snapshot you are creating (here, since you didn't use <disk
snapshot='no'> in the domain xml, and didn't specify vdb in the
<domainsnapshot>, libvirt assumes from --disk-only that you want vdb to
have an external snapshot taken).
</domainsnapshot>
What am I doing wrong - how can I tell snapshot-create-as to create an external snapshot
for a specific block device only (not all block devices)?
Use: --diskspec vda --diskspec vdb,snapshot=no
which produces this subset of xml:
<disks>
<disk name='vda'/>
<disk name='vdb' snapshot='no'/>
</disks>
Also, while looking at the manpage, does the --live option do anything different if used
with the above command?
--live only makes sense when mixed with memory snapshots (with
--memspec); but as you are doing a --disk-only snapshot, it doesn't help
(I'm not sure if it will error out as mutually exclusive or just be
silently ignored, without reading the code).
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
10:41 p.m.
----- Original Message -----
From: "Eric Blake" <eblake(a)redhat.com> To:
"Andrew Martin"
<amartin(a)xes-inc.com>, libvirt-users(a)redhat.com Sent: Thursday, May 22, 2014
5:44:54 PM Subject: Re: [libvirt-users] Live snapshots of a single block
device
On 05/22/2014 04:31 PM, Andrew Martin wrote:
> Hello,
>
[Can you convince your mailer to wrap long lines?]
Sorry, my client won't
auto-wrap and I forgot to run my post through vim before
sending. Will do now :)
> I am working on a script to automatically create live snapshots of running
> VMs using qemu-kvm 1.4.0 and libvirt 1.0.2. If a VM has
Any reason you aren't upgrading to newer versions? Although these seem
sufficient for what you are trying.
The VM hosts I'm using all run Ubuntu 12.04
and I haven't had time to backport
and test newer versions yet. I've published the latest versions I built in this
PPA: https://launchpad.net/~xespackages/+archive/virtualization
The main functionality I need is live snapshotting with snapshot-create-as and
blockpull, so I haven't had a good reason to invest time to upgrade.
The problem you are facing is that the snapshot code MUST have an action for
every disk; and if you don't specify the action directly in your
<domainsnapshot> xml, then the action chosen is inherited from the <domain>
xml (if you used <disk snapshot='no'>) or ultimately from the type of
snapshot
you are creating (here, since you didn't use <disk snapshot='no'> in
the
domain xml, and didn't specify vdb in the <domainsnapshot>, libvirt
assumes from --disk-only that you want vdb to have an external
snapshot taken).
> </domainsnapshot>
>
> What am I doing wrong - how can I tell snapshot-create-as to create an
> external snapshot for a specific block device only (not all block devices)?
Use: --diskspec vda --diskspec vdb,snapshot=no
which produces this subset of xml:
<disks> <disk name='vda'/> <disk name='vdb'
snapshot='no'/> </disks>
Ah, that makes sense, thanks so much for clearing this up!
>
> Also, while looking at the manpage, does the --live option do anything
> different if used with the above command?
--live only makes sense when mixed with memory snapshots (with --memspec); but
as you are doing a --disk-only snapshot, it doesn't help (I'm not sure if it
will error out as mutually exclusive or just be silently ignored,
without reading the code).
I'm using this code in a script for creating live
backups of VMs - would it make
sense to include --memspec to capture the memory state so that an fsck on boot
isn't necessary? I remember you explained --quiese awhile back:
https://www.redhat.com/archives/libvirt-users/2013-February/msg00020.html
However I don't have qemu-guest-agent installed on the guests, so would using
--memspec instead of --disk-only produce a snapshot that is consistent (since it
would "resume" with the same memory state) or would this not be ideal
for backups (e.g easy to restore/recover)? Can the memory image be written to
the same image file (qcow2) as the disk snapshot?
Thanks,
Andrew
12:51 a.m.
On 05/23/2014 08:41 AM, Andrew Martin wrote:
>
> Any reason you aren't upgrading to newer versions? Although these seem
> sufficient for what you are trying.
The VM hosts I'm using all run Ubuntu 12.04 and I haven't had time to backport
and test newer versions yet. I've published the latest versions I built in this
PPA: https://launchpad.net/~xespackages/+archive/virtualization
One of the benefits of newer qemu is the ability to do point-in-time
snapshots without altering the backing chain in use by the active disk
(well, qemu 2.0 has some improvements, and unreleased qemu 2.1 has even
more in the pipeline; and it takes newer qemu to drive some of these
improvements). Some of these new approaches may provide enough
additional efficiency over the older methods that they are worth
upgrading for - but if you can get things working to your needs with an
older version, great.
> --live only makes sense when mixed with memory snapshots (with
--memspec); but
> as you are doing a --disk-only snapshot, it doesn't help (I'm not sure if it
> will error out as mutually exclusive or just be silently ignored,
> without reading the code).
I'm using this code in a script for creating live backups of VMs - would it make
sense to include --memspec to capture the memory state so that an fsck on boot
isn't necessary? I remember you explained --quiese awhile back:
https://www.redhat.com/archives/libvirt-users/2013-February/msg00020.html
--memspec and --quiesce are orthogonal, you only need one or the other
(in fact, they do NOT work together in the current implementation).
--memspec says to capture the domain memory state (migrate to file;
using --live additionally says to minimize the time the guest is paused
but the file may be larger), and when the guest pauses at the end of
that migration, then snapshot the disks. By resuming the guest from
that migration stream and disk state, any pending I/O operations in
flight in the guest OS will still be ready to go when the guest starts
back up, no fsck needed. --quiesce says to tell the guest to flush all
I/O, then captures disk state, all without stopping the guest. But
--quiesce requires the guest to be running to work, while --memspec
forceably stops the guest (the migration algorithm must pause, even if
--live minimizes the pause to a fraction of a second).
However I don't have qemu-guest-agent installed on the guests, so would using
--memspec instead of --disk-only produce a snapshot that is consistent (since it
would "resume" with the same memory state) or would this not be ideal
for backups (e.g easy to restore/recover)? Can the memory image be written to
the same image file (qcow2) as the disk snapshot?
External checkpoints (those where --memspec was used) have more
information than disk-only snapshots (even if --quiesce was used to
minimze the need for an fsck on the disk contents). Thus, --memspec
snapshots require no guest cooperation, at the expense of requiring more
disk space to hold the state. On the other hand, if you are going to do
a --memspec snapshot, I _highly_ recommend that you snapshot ALL disks
at once, rather than trying to do just one disk at a time. With
--disk-only (whether or not you use --quiesce), all you can recover is
the disk state by a fresh boot of the disk (--quiesce minimizes the
chance that the fresh boot needs an fsck). But with --memspec, the
memory state is only consistent if it matches ALL disk state taken at
the same time as the memory state - if you omit a disk, then try to
revert to that memory state, your running guest will behave as if the
disk instantaneously corrupted data out of underneath the OS.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
2:16 a.m.
>> --live only makes sense when mixed with memory snapshots
(with --memspec);
>> but
>> as you are doing a --disk-only snapshot, it doesn't help (I'm not sure
if
>> it
>> will error out as mutually exclusive or just be silently ignored,
>> without reading the code).
> I'm using this code in a script for creating live backups of VMs - would it
> make
> sense to include --memspec to capture the memory state so that an fsck on
> boot
> isn't necessary? I remember you explained --quiese awhile back:
> https://www.redhat.com/archives/libvirt-users/2013-February/msg00020.html
--memspec and --quiesce are orthogonal, you only need one or the other
(in fact, they do NOT work together in the current implementation).
--memspec says to capture the domain memory state (migrate to file;
using --live additionally says to minimize the time the guest is paused
but the file may be larger), and when the guest pauses at the end of
that migration, then snapshot the disks. By resuming the guest from
that migration stream and disk state, any pending I/O operations in
flight in the guest OS will still be ready to go when the guest starts
back up, no fsck needed. --quiesce says to tell the guest to flush all
I/O, then captures disk state, all without stopping the guest. But
--quiesce requires the guest to be running to work, while --memspec
forceably stops the guest (the migration algorithm must pause, even if
--live minimizes the pause to a fraction of a second).
Would calling
snapshot-create-as with --disk-only and --quiese still succeed
on a VM that is stopped (since the disk would already be consistent, it would
just call "qemu-img create")?
>
> However I don't have qemu-guest-agent installed on the guests, so would
> using
> --memspec instead of --disk-only produce a snapshot that is consistent
> (since it
> would "resume" with the same memory state) or would this not be ideal
> for backups (e.g easy to restore/recover)? Can the memory image be written
> to
> the same image file (qcow2) as the disk snapshot?
External checkpoints (those where --memspec was used) have more
information than disk-only snapshots (even if --quiesce was used to
minimze the need for an fsck on the disk contents). Thus, --memspec
snapshots require no guest cooperation, at the expense of requiring more
disk space to hold the state. On the other hand, if you are going to do
a --memspec snapshot, I _highly_ recommend that you snapshot ALL disks
at once, rather than trying to do just one disk at a time. With
--disk-only (whether or not you use --quiesce), all you can recover is
the disk state by a fresh boot of the disk (--quiesce minimizes the
chance that the fresh boot needs an fsck). But with --memspec, the
memory state is only consistent if it matches ALL disk state taken at
the same time as the memory state - if you omit a disk, then try to
revert to that memory state, your running guest will behave as if the
disk instantaneously corrupted data out of underneath the OS.
It sounds like
--quiese would work better for my use case, since I'm only
concerned with keeping the disk state consistent and prefer to not stop
the guest (even for a fraction of a second). The qemu-kvm 1.4.0 package
I built includes a version of qemu-guest-agent 1.4.0, so I will start
testing after installing it in a guest and adding the XML to the config:
http://wiki.libvirt.org/page/Qemu_guest_agent
Thanks!
Andrew
8:30 a.m.
On 05/23/2014 12:16 PM, Andrew Martin wrote:
> --quiesce requires the guest to be running to work, while
--memspec
> forceably stops the guest (the migration algorithm must pause, even if
> --live minimizes the pause to a fraction of a second).
Would calling snapshot-create-as with --disk-only and --quiese still succeed
on a VM that is stopped (since the disk would already be consistent, it would
just call "qemu-img create")?
For an offline guest, --disk-only makes no difference (there is no
memory to worry about); and you are correct that the disk is consistent
(assuming the OS has a clean shutdown before going offline). Yes,
calling 'qemu-img create' is basically what libvirt does for an offline
external snapshot.
However, a paused/stopped guest cannot respond to a quiesce request (the
guest agent only works if the guest is running), so your attempt to use
--quiesce would fail; you'd have to omit the parameter if the guest is
stopped.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
11:41 p.m.
----- Original Message -----
From: "Eric Blake" <eblake(a)redhat.com>
To: "Andrew Martin" <amartin(a)xes-inc.com>
Cc: libvirt-users(a)redhat.com
Sent: Friday, May 23, 2014 7:30:44 PM
Subject: Re: [libvirt-users] Live snapshots of a single block device
On 05/23/2014 12:16 PM, Andrew Martin wrote:
>> --quiesce requires the guest to be running to work, while --memspec
>> forceably stops the guest (the migration algorithm must pause, even if
>> --live minimizes the pause to a fraction of a second).
> Would calling snapshot-create-as with --disk-only and --quiese still
> succeed
> on a VM that is stopped (since the disk would already be consistent, it
> would
> just call "qemu-img create")?
For an offline guest, --disk-only makes no difference (there is no
memory to worry about); and you are correct that the disk is consistent
(assuming the OS has a clean shutdown before going offline). Yes,
calling 'qemu-img create' is basically what libvirt does for an offline
external snapshot.
However, a paused/stopped guest cannot respond to a quiesce request (the
guest agent only works if the guest is running), so your attempt to use
--quiesce would fail; you'd have to omit the parameter if the guest is
stopped.
Okay, that makes sense to me. Thanks for the clarification!
Andrew
3806
days inactive
3818
days old
6 comments
2 participants
participants (2)
-
Andrew Martin -
Eric Blake