On 26.03.2015 15:48, Pavel Boldin wrote: > Dear Libvirt Developers, > > > I'm working to implement feature request [1]. The feature request proposes > to enhance `libvirt' code so the API caller can specify which block devices > are to be migrated using e.g. parameters in the `virDomainMigrateToURI3' > call. Correct. My idea is to add pairs of typed parameters to the virDomainMigrate3() and virDomainMigrateToURI3() API. These are the only migrate APIs that accept virTypedParameter. The rest of migrate APIs are just too old and not extensible, so they must continue working as they are now. However, those two APIs - they can be passed new pairs, e.g. ("migrate_disk", "vda"). Now, mgmt applications will want to specify more than one disk to migrate, obviously. We have two options: 1) make "migrate_disk" accept stringyfied array of disk targets, e.g. "migrate_disk": "vda,vdb,sda". This is not so pleasant to work with from client applications. Constructing the string would be awful. 2) make virTypedParam* APIs accept more than one values to a key, e.g. {("migrate_disk", "vda"), ("migrate_disk", "vdb"), ("migrate_disk", "sda")}. Currently, this is supported on RPC, but some virTypedParam* APIs are not really prepared for this. If I had to name some from the top of my head: virTypedParamsGet(). I view virTyped* as an associative array. So 2) is practically enabling multi value associative array. So I guess the first step would be to introduce new API (maybe set of APIs?) that are aware of this. Then, virDomainMigrate*3() can just use this in the following way: a) when no "migrate_disk" is specified, the current behaviour is preserved b) when there are some disk selected for storage migration, since at this point we have virTyped* APIs to work with multivalue, we can get the array of disk targets to migrate and instruct qemu to just migrate them. Now, qemu has split storage and internal state migration into two streams. The first one is called NBD and libvirt selectively choses disks to migrate. For the other stream you don't have to care about. Look at qemuMigrationDriveMirror() and you'll see how libvirt instructs qemu to selectively migrate only some disks. The "migrate_disk" array would need to be propagated down here then. Hopefully I haven't forgot nothing. Michal -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list