[libvirt] RFC backup API

[John Snow]

On 03/25/2016 05:34 AM, Maxim Nestratov wrote:
> 23.03.2016 17:27, John Snow пишет:
>>
>> On 03/23/2016 06:36 AM, Kashyap Chamarthy wrote:
>>> On Mon, Mar 21, 2016 at 01:18:19PM +0300, Maxim Nestratov wrote:
>>>> Hi all,
>>>>
>>>> It's been already quite a long time since qemu implemented QMP
>>>> "drive-backup" command to create block devices backups. Even more,
>>>> since qemu 2.4 there is a possibility to create incremental backups.
>>>> Though it is possible to backup all attached to a domain disk drives
>>>> by combining them into a single QMP transaction command, this way of
>>>> creating them, not to mention managing, remains inconvenient for an
>>>> end user of libvirt. Moreover, creating a single drive backup via QMP
>>>> interface isn't handy either. That said, it looks reasonable to
>>>> introduce a *new backup API* based on QMP "drive-backup" facilities.
>>> There's also the 'blockdev-backup' command, which seems similar in
>>> operation to 'drive-backup', but differs subtly.
>>>
>>> Looking at qmp-commands.hx, I learn that 'blockdev-backup' accepts
>>> target ID; while 'drive-backup' accept target drive name, otherwise,
>>> their operation look almost identical, and both commands use
>>> backup_start() (from qemu/blockdev.c).  [Added John Snow in CC to
>>> correct me if I'm wrong.]
>>>
>> No, you're right. Blockdev-backup can backup to an arbitrary device
>> (which can be backed by a new file), but drive-backup will only accept a
>> new file.
>>
>> I don't think blockdev-backup supports incremental backups just yet, but
>> I don't think there's any reason it can't. (Looking at it: yeah, why
>> have I not done that yet?...)
> 
> John,
> Any chances to get this implemented? Just not to use two different
> commands in libvirt and start using 'blockdev-backup' right away for
> both full and incremental backups?
> 

Yes, it'd be very trivial to do... but I think there is some debate
currently about how to change how incrementals work, so it might not be
wise for me to do this until I know what the situation is, to avoid
having to retcon _two_ QMP interfaces instead of just the one.

(The debate revolves around how bitmaps exist as an in-memory object and
how to present them to the user -- as objects that attach to /drives/,
or to /nodes/, or to both. We haven't answered this question for
ourselves yet, which precludes API design.)

>>> For 'blockdev-backup'
>>> ---------------------
>>>
>>> -> { "execute": "blockdev-backup", "arguments": { "device": "src-id",
>>>                                                    "sync": "full",
>>>                                                    "target": "tgt-id"
>>> } }
>>> <- { "return": {} }
>>>
>>>
>>> Where 'tagert' in this case means:
>>>
>>>      "the name of the backup target device. (json-string)"
>>>
>>>
>>> For 'drive-backup'
>>> -----------------
>>>
>>> -> { "execute": "drive-backup", "arguments": { "device": "drive0",
>>>                                                 "sync": "full",
>>>                                                 "target":
>>> "backup.img" } }
>>> <- { "return": {} }
>>>
>>> Here, 'target' means:
>>>
>>>          "the target of the new image. If the file exists, or if it is a
>>>          device, the existing file/device will be used as the new
>>>          destination.  If it does not exist, a new file will be created.
>>>          (json-string)"
>>>
>>> [...]
>>>
>>>
>> --js
>