From: Kashyap Chamarthy <kchamart@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Zhang Haoyu <zhanghy@sangfor.com.cn>,
qemu-devel <qemu-devel@nongnu.org>, kvm <kvm@vger.kernel.org>,
Fam Zheng <famz@redhat.com>,
Stefan Hajnoczi <stefanha@redhat.com>
Subject: Re: [Qemu-devel] [question] incremental backup a running vm
Date: Fri, 23 Jan 2015 12:09:58 +0100 [thread overview]
Message-ID: <20150123110958.GA14654@tesla.redhat.com> (raw)
In-Reply-To: <54BF81F0.9070908@redhat.com>
On Wed, Jan 21, 2015 at 11:39:44AM +0100, Paolo Bonzini wrote:
>
>
> On 21/01/2015 11:32, Zhang Haoyu wrote:
> > Hi,
> >
> > Does drive_mirror support incremental backup a running vm?
> > Or other mechanism does?
> >
> > incremental backup a running vm requirements:
> > First time backup, all of the allocated data will be mirrored to destination,
> > then a copied bitmap will be saved to a file, then the bitmap file will log dirty for
> > the changed data.
> > Next time backup, only the dirty data will be mirrored to destination.
> > Even the VM shutdown and start after several days,
> > the bitmap will be loaded while starting vm.
> > Any ideas?
>
> Drive-mirror is for storage migration. For backup there is another job,
> drive-backup. drive-backup copies a point-in-time snapshot of one or
> more disks corresponding to when the backup was started.
Zhang, I've been testing the `drive-backup` command via QMP for a little
while, and it works reasonably well. If you'd like to test it you can
quickly try as below, once you have a QEMU instance runing with QMP
(I invoke my QEMU instances with '-qmp tcp:localhost:4444,server').
The below script invokes the 'drive-backup' QMP command (Ensure you're
using the correct disk, your disk ID might be 'drive-virtio-disk1' :-) )
-----------------
#!/bin/bash
set -x
exec 3<>/dev/tcp/localhost/4444
echo -e "{ 'execute': 'qmp_capabilities' }" >&3
read response <&3
echo $response
echo -e "{ 'execute': 'drive-backup', 'arguments':
{ 'device': 'drive-virtio-disk0', 'sync': 'full', 'target':
'/export/backup-of-vm1.qcow2', 'mode': 'absolute-paths', 'format': 'qcow2' } }" >&3
read response <&3
echo $response
-----------------
Once the above is invoked succesfully, you can see the success of the
command on the shell where your QMP server is running:
-----------------
[. . .]
char device redirected to /dev/pts/8 (label charserial0)
QEMU waiting for connection on: disconnected:tcp:localhost:4444,server
Formatting '/export/backup-of-vm1.qcow2', fmt=qcow2 size=53687091200 encryption=off cluster_size=65536 lazy_refcounts=off
-----------------
>
> Incremental backup is being worked on. You can see patches on the list.
>
> Paolo
>
--
/kashyap
WARNING: multiple messages have this Message-ID (diff)
From: Kashyap Chamarthy <kchamart@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Stefan Hajnoczi <stefanha@redhat.com>,
Zhang Haoyu <zhanghy@sangfor.com.cn>, Fam Zheng <famz@redhat.com>,
qemu-devel <qemu-devel@nongnu.org>, kvm <kvm@vger.kernel.org>
Subject: Re: [Qemu-devel] [question] incremental backup a running vm
Date: Fri, 23 Jan 2015 12:09:58 +0100 [thread overview]
Message-ID: <20150123110958.GA14654@tesla.redhat.com> (raw)
In-Reply-To: <54BF81F0.9070908@redhat.com>
On Wed, Jan 21, 2015 at 11:39:44AM +0100, Paolo Bonzini wrote:
>
>
> On 21/01/2015 11:32, Zhang Haoyu wrote:
> > Hi,
> >
> > Does drive_mirror support incremental backup a running vm?
> > Or other mechanism does?
> >
> > incremental backup a running vm requirements:
> > First time backup, all of the allocated data will be mirrored to destination,
> > then a copied bitmap will be saved to a file, then the bitmap file will log dirty for
> > the changed data.
> > Next time backup, only the dirty data will be mirrored to destination.
> > Even the VM shutdown and start after several days,
> > the bitmap will be loaded while starting vm.
> > Any ideas?
>
> Drive-mirror is for storage migration. For backup there is another job,
> drive-backup. drive-backup copies a point-in-time snapshot of one or
> more disks corresponding to when the backup was started.
Zhang, I've been testing the `drive-backup` command via QMP for a little
while, and it works reasonably well. If you'd like to test it you can
quickly try as below, once you have a QEMU instance runing with QMP
(I invoke my QEMU instances with '-qmp tcp:localhost:4444,server').
The below script invokes the 'drive-backup' QMP command (Ensure you're
using the correct disk, your disk ID might be 'drive-virtio-disk1' :-) )
-----------------
#!/bin/bash
set -x
exec 3<>/dev/tcp/localhost/4444
echo -e "{ 'execute': 'qmp_capabilities' }" >&3
read response <&3
echo $response
echo -e "{ 'execute': 'drive-backup', 'arguments':
{ 'device': 'drive-virtio-disk0', 'sync': 'full', 'target':
'/export/backup-of-vm1.qcow2', 'mode': 'absolute-paths', 'format': 'qcow2' } }" >&3
read response <&3
echo $response
-----------------
Once the above is invoked succesfully, you can see the success of the
command on the shell where your QMP server is running:
-----------------
[. . .]
char device redirected to /dev/pts/8 (label charserial0)
QEMU waiting for connection on: disconnected:tcp:localhost:4444,server
Formatting '/export/backup-of-vm1.qcow2', fmt=qcow2 size=53687091200 encryption=off cluster_size=65536 lazy_refcounts=off
-----------------
>
> Incremental backup is being worked on. You can see patches on the list.
>
> Paolo
>
--
/kashyap
next prev parent reply other threads:[~2015-01-23 11:10 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-21 10:32 [question] incremental backup a running vm Zhang Haoyu
2015-01-21 10:32 ` [Qemu-devel] " Zhang Haoyu
2015-01-21 10:39 ` Paolo Bonzini
2015-01-21 10:39 ` [Qemu-devel] " Paolo Bonzini
2015-01-22 23:29 ` Kashyap Chamarthy
2015-01-22 23:29 ` [Qemu-devel] " Kashyap Chamarthy
2015-01-26 1:07 ` Zhang Haoyu
2015-01-26 1:07 ` [Qemu-devel] " Zhang Haoyu
2015-01-26 9:29 ` Paolo Bonzini
2015-01-26 9:29 ` [Qemu-devel] " Paolo Bonzini
2015-01-26 11:13 ` Zhang Haoyu
2015-01-26 11:13 ` [Qemu-devel] " Zhang Haoyu
2015-01-26 11:28 ` Paolo Bonzini
2015-01-26 11:28 ` [Qemu-devel] " Paolo Bonzini
2015-01-26 12:25 ` Zhang Haoyu
2015-01-26 12:25 ` [Qemu-devel] " Zhang Haoyu
2015-01-23 11:09 ` Kashyap Chamarthy [this message]
2015-01-23 11:09 ` Kashyap Chamarthy
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=20150123110958.GA14654@tesla.redhat.com \
--to=kchamart@redhat.com \
--cc=famz@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.com \
--cc=zhanghy@sangfor.com.cn \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.