Re: [libvirt] RFC backup API

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?...)

> 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