All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Denis V. Lunev" <den@virtuozzo.com>
To: John Snow <jsnow@redhat.com>, Stefan Hajnoczi <stefanha@gmail.com>
Cc: kwolf@redhat.com,
	Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>,
	Fam Zheng <famz@redhat.com>,
	qemu-devel@nongnu.org, armbru@redhat.com
Subject: Re: [Qemu-devel] [PATCH v2 0/6] external backup api
Date: Tue, 9 Feb 2016 19:58:19 +0300	[thread overview]
Message-ID: <56BA1AAB.7040504@virtuozzo.com> (raw)
In-Reply-To: <56BA1888.7050308@redhat.com>

On 02/09/2016 07:49 PM, John Snow wrote:
>
> On 02/09/2016 09:37 AM, Denis V. Lunev wrote:
>> On 02/09/2016 05:21 PM, Stefan Hajnoczi wrote:
>>> On Fri, Feb 05, 2016 at 11:28:42AM +0300, Denis V. Lunev wrote:
>>>> On 02/03/2016 11:14 AM, Fam Zheng wrote:
>>>>> On Sat, 01/30 13:56, Vladimir Sementsov-Ogievskiy wrote:
>>>>>> Hi all.
>>>>>>
>>>>>> These series which aims to add external backup api. This is needed
>>>>>> to allow
>>>>>> backup software use our dirty bitmaps.
>>>>>>
>>>>>> Vmware and Parallels Cloud Server have this feature.
>>>>> What is the advantage of this appraoch over "drive-backup
>>>>> sync=incremental
>>>>> ..."?
>>>> This will allow third-party vendors to backup QEMU VMs into
>>>> their own formats or to the cloud etc.
>>> Backup software can implement NBD to receive the incremental blocks from
>>> QEMU.  Use drive-backup sync=incremental and the backup appliance as the
>>> NBD target.
>>>
>>> It's more complicated to add this QMP command flow to backup software
>>> than to implement NBD.
>>>
>>> Stefan
>> it can, but this is a matter of problem due to the nature of
>> how this software is implemented. Usually it is written
>> in a semi-standard way and it uses "plugins" to actually
>> collect the data, i.e. the code is written in standard
>> interface/real implementation pattern and interfaces are
>> basically the same.
>>
>> With this standard approach backup software is working
>> as an active side of the process, i.e. it performs operations
>> and controls the flow.
>>
>> This means that "non-standard" QEMU technology will be
>> pain here.
>>
>> Den
> Am I to understand that for e.g. VMWare the backup appliance is
> literally reading the disk image from storage directly while the VM is
> running?
>
> I'd be a bit surprised if that were true.
I think that backup software is asking alive VM about the data.

> My biggest concern here is that there is not a safe way, today, to read
> from a disk image atomically while the VM is running. I think that'd
> take a lot of work to do and you'll not find a lot of support in
> implementing it.
>
> Of course, while the VM is paused/off is a different story, but for now
> I still feel like NBD is the right answer for getting block data from QEMU.
>
> What am I missing?
>
> --js
In general, in Parallels Server the backup was created using the
following approach:
- create external snapshot. In this case the base image (backing store 
in QEMU terminology)
   will be READ-ONLY and could be safely read by any entity
- backup that read-only disk image (any way)
- merge snapshots

In this process backup software is active while PCS is passive.
With QEMU the approach looks the same to me:
- start a backup
- ask QEMU to give a data to be backuped (using NBD server in QEMU
   with Fam's image fleecing)
- finish backup

Important bit here is that dirty bitmap should be provided
by QEMU by request. This dirty bitmap will be read-only at that
moment, current active dirty bitmap should be replaced with
new at backup start operation.

Den

  reply	other threads:[~2016-02-09 16:58 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-30 10:56 [Qemu-devel] [PATCH v2 0/6] external backup api Vladimir Sementsov-Ogievskiy
2016-01-30 10:56 ` [Qemu-devel] [PATCH 1/6] block dirty bitmap: add next_zero function Vladimir Sementsov-Ogievskiy
2016-01-30 10:56 ` [Qemu-devel] [PATCH 2/6] qmp: add query-block-dirty-bitmap-ranges Vladimir Sementsov-Ogievskiy
2016-02-10 10:08   ` Stefan Hajnoczi
2016-02-10 13:57     ` Denis V. Lunev
2016-02-10 15:26       ` John Snow
2016-02-10 15:36         ` Denis V. Lunev
2016-02-10 15:37           ` John Snow
2016-02-10 15:40             ` Denis V. Lunev
2016-02-14  5:05       ` Fam Zheng
2016-01-30 10:56 ` [Qemu-devel] [PATCH 3/6] iotests: test query-block-dirty-bitmap-ranges Vladimir Sementsov-Ogievskiy
2016-01-30 10:56 ` [Qemu-devel] [PATCH 4/6] qapi: add qmp commands for some dirty bitmap functions Vladimir Sementsov-Ogievskiy
2016-01-30 10:56 ` [Qemu-devel] [PATCH 5/6] qapi: make block-dirty-bitmap-create-successor transaction-able Vladimir Sementsov-Ogievskiy
2016-01-30 10:56 ` [Qemu-devel] [PATCH 6/6] iotests: test external backup api Vladimir Sementsov-Ogievskiy
2016-02-03  8:14 ` [Qemu-devel] [PATCH v2 0/6] " Fam Zheng
2016-02-03 10:57   ` Vladimir Sementsov-Ogievskiy
2016-02-03 11:02     ` Fam Zheng
2016-02-03 11:24       ` Vladimir Sementsov-Ogievskiy
2016-02-05  8:28   ` Denis V. Lunev
2016-02-05  8:44     ` Fam Zheng
2016-02-09 14:21     ` Stefan Hajnoczi
2016-02-09 14:37       ` Denis V. Lunev
2016-02-09 16:49         ` John Snow
2016-02-09 16:58           ` Denis V. Lunev [this message]
2016-02-09 18:12             ` John Snow
2016-02-09 19:25               ` Denis V. Lunev
2016-02-10  8:04                 ` Denis V. Lunev
2016-02-09 14:28     ` Stefan Hajnoczi
2016-02-09 14:41       ` Denis V. Lunev
2016-02-10 10:10         ` Stefan Hajnoczi
2016-02-16 17:09           ` Stefan Hajnoczi
2016-02-16 17:17             ` Vladimir Sementsov-Ogievskiy
2016-02-16 17:20             ` Denis V. Lunev
2016-02-18 16:39               ` Stefan Hajnoczi
2016-02-18 17:07                 ` Markus Armbruster
2016-02-17 17:47             ` Vladimir Sementsov-Ogievskiy
2016-02-18  0:59               ` Fam Zheng
2016-02-18 12:11               ` Daniel P. Berrange
2016-02-18 16:41                 ` Stefan Hajnoczi
2016-02-19  2:08                   ` Fam Zheng
2016-02-19  8:51                     ` Markus Armbruster
2016-02-24 23:34                       ` John Snow
2016-02-26 19:55                       ` Paolo Bonzini
2016-02-26 20:03                         ` Paolo Bonzini
2016-02-26 20:29                           ` Denis V. Lunev
2016-02-26 21:37                           ` John Snow
2016-02-26 20:40                         ` Denis V. Lunev
2016-02-27  4:26                           ` Fam Zheng
2016-02-29  8:14                         ` Markus Armbruster
2016-02-29  8:54                           ` Paolo Bonzini
2016-02-29  9:42                             ` Paolo Bonzini
2016-02-29 10:05                               ` Fam Zheng
2016-03-10 17:37                               ` Stefan Hajnoczi
2016-03-10 17:40                                 ` Paolo Bonzini
2016-03-14 16:27                                   ` Denis V. Lunev
2016-02-29 10:22                           ` Markus Armbruster

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=56BA1AAB.7040504@virtuozzo.com \
    --to=den@virtuozzo.com \
    --cc=armbru@redhat.com \
    --cc=famz@redhat.com \
    --cc=jsnow@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@gmail.com \
    --cc=vsementsov@virtuozzo.com \
    /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.