On 02/19/2016 03:51 AM, Markus Armbruster wrote: > Fam Zheng <f...@redhat.com> writes: > >> On Thu, 02/18 16:41, Stefan Hajnoczi wrote: >>> On Thu, Feb 18, 2016 at 12:11:14PM +0000, Daniel P. Berrange wrote: >>>> On Wed, Feb 17, 2016 at 08:47:11PM +0300, Vladimir Sementsov-Ogievskiy >>>> wrote: >>>>> On 16.02.2016 20:09, Stefan Hajnoczi wrote: >>>>>> On Wed, Feb 10, 2016 at 10:10:04AM +0000, Stefan Hajnoczi wrote: >>>>>>> On Tue, Feb 09, 2016 at 05:41:50PM +0300, Denis V. Lunev wrote: >>>>>>>> On 02/09/2016 05:28 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. >>>>>>>>> As an example, there is a third-party backup format called VMA from >>>>>>>>> Proxmox. A few years ago I posted a proof-of-concept external backup >>>>>>>>> tool in Python: >>>>>>>>> >>>>>>>>> https://lists.gnu.org/archive/html/qemu-devel/2013-03/msg01536.html >>>>>>>>> >>>>>>>>> It takes a full backup using drive-backup NBD (plus RAM/device state) >>>>>>>>> but the same can be done with incremental backups. >>>>>>>>> >>>>>>>>> Does this NBD approach meet your requirements? >>>>>>>>> >>>>>>>>> Stefan >>>>>>>> for us we should somehow provide implementation of >>>>>>>> calls posted by Vladimir. They are available in Parallels Server >>>>>>>> version 6 and should be available in the next QEMU based >>>>>>>> release using "Parallels SDK to libvirt" convertor. The problem >>>>>>>> for us is that this old approach is used in the other side >>>>>>>> of the product - in containers implementation while this >>>>>>>> SDK is a universal access tool to both things. >>>>>>> Point taken. I think many other backup applications will expect a >>>>>>> similar API, so it's pragmatic to provide something compatible. >>>>>> Kevin Wolf and Daniel Berrange proposed an elegant way to avoid the >>>>>> concerns about the QMP monitor: >>>>>> >>>>>> Previously I described incremental backup in "push" mode (already >>>>>> supported today with drive-backup). QEMU connects to a remote NBD >>>>>> server and writes out the contents of all dirty blocks: >>>>>> >>>>>> QEMU ---Write dirty blocks--> Backup appliance (server) >>>>>> >>>>>> This doesn't lend itself well to existing backup applications that >>>>>> expect to iterate the dirty bitmap manually. >>>>>> >>>>>> Let's add a "pull" mode where the connection of the NBD connection is >>>>>> reversed. The backup application connects to QEMU's NBD server (image >>>>>> fleecing). The NBD protocol is extended to support the SCSI Get LBA >>>>>> Status command for querying block provisioning information. Now the >>>>>> backup application can use Get LBA Status to fetch the dirty block >>>>>> information from QEMU. >>>>>> >>>>>> QEMU (server) <--Get LBA Status or Read dirty blocks-- Backup appliance >>>>>> >>>>>> The dirty block information goes over the same NBD connection used to >>>>>> read the contents of the dirty blocks. The QMP monitor is not used to >>>>>> transfer dirty block information. >>>>>> >>>>>> It may be necessary to extend the nbd-server-add command so that a >>>>>> bitmap name can be passed. This bitmap will be used to answer Get LBA >>>>>> Status queries instead of using on bdrv_co_get_block_status(). This >>>>>> would be necessary if image fleecing (point in time snapshot) is used. >>>>>> >>>>>> Stefan >>>>> >>>>> There are no such commands in nbd spec here: >>>>> >>>>> https://github.com/yoe/nbd/blob/master/doc/proto.md >>>>> >>>>> >>>>> So, I'm not sure, that adding something qemu-specific to this external >>>>> protocol will be simple or even true way. Is Qemu already extending >>>>> original >>>>> nbd? >>>> >>>> No, we don't do any QEMU specific extensions. The point of the approach >>>> Stefan suggests here though, is that it is *not* an inherantly >>>> QEMU-specific >>>> concept, it is relevant to any NBD server implementation. >>>> >>>> For example, consider you were using a regular NBD server to export a >>>> sparse LVM volume. This proposed extension would be relevant to such >>>> a use case. As such this proposed extension is something that is likely >>>> to be acceptable for the generic NBD specification. >>> >>> Yes, Get LBA Status could be useful for non-QEMU NBD users too. >>> >>> NBD already supports a TRIM command so the ability to query the >>> allocation status is a natural feature to add. >> >> Is it an abuse to "Get LBA Status" to return dirty information? Because in >> SCSI >> the command reports "mapped", "allocated" and "anchored" statuses. Does that >> mean NBD will use a different status set? > > Perhaps some conceptual gymnastics can get us to standard semantics. > > Incremental backup wants to copy out an image's "dirty" blocks. > > We can view this as a bitmap telling us which of the image's blocks are > dirty. > > An alternative view would be base image + dirty delta image. In the the > dirty delta, exactly the dirty blocks are allocated. The delta image > may be conceptual. > > Now, consider the dirty delta *without* its backing image. You can find > its allocated blocks with Get LBA Status. As usual, you can read even > unallocated blocks, see SBC3 table 9. > > If we NBD-export exactly that, we can use standard semantics, can't we? >
Sounds exactly appropriate to me, from this perspective. If absolutely necessary we could disguise this behind a macro QMP command that implied these exact kind of semantics for the fleecing/NBD export -- one that accepted the bitmap name to tie to the export for this reason. --js
