<div dir="ltr">Michal,<br><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Apr 15, 2015 at 10:54 AM, Michal Privoznik <span dir="ltr"><<a href="mailto:mprivozn@redhat.com" target="_blank">mprivozn@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">On <a href="tel:26.03.2015%2015" value="+12603201515">26.03.2015 15</a>:48, Pavel Boldin wrote:<br>
> Dear Libvirt Developers,<br>
><br>
><br>
> I'm working to implement feature request [1]. The feature request proposes<br>
> to enhance `libvirt' code so the API caller can specify which block devices<br>
> are to be migrated using e.g. parameters in the `virDomainMigrateToURI3'<br>
> call.<br>
<br>
</span>Correct. My idea is to add pairs of typed parameters to the<br>
virDomainMigrate3() and virDomainMigrateToURI3() API. These are the only<br>
migrate APIs that accept virTypedParameter. The rest of migrate APIs are<br>
just too old and not extensible, so they must continue working as they<br>
are now. However, those two APIs - they can be passed new pairs, e.g.<br>
("migrate_disk", "vda"). Now, mgmt applications will want to specify<br>
more than one disk to migrate, obviously. We have two options:<br>
<br>
1) make "migrate_disk" accept stringyfied array of disk targets, e.g.<br>
"migrate_disk": "vda,vdb,sda". This is not so pleasant to work with from<br>
client applications. Constructing the string would be awful.<br></blockquote><div>My concern was that some drivers may allow commas inside the drive names. So this is obviously wrong thing to do then.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
2) make virTypedParam* APIs accept more than one values to a key, e.g.<br>
{("migrate_disk", "vda"), ("migrate_disk", "vdb"), ("migrate_disk",<br>
"sda")}. Currently, this is supported on RPC, but some virTypedParam*<br>
APIs are not really prepared for this. If I had to name some from the<br>
top of my head: virTypedParamsGet().<br></blockquote><div>As far as I see there is a line 420 in src/util/virtypedparam.c:<br>/* The following APIs are public and their signature may never change. */<br><br></div><div>So, the functions need to be implemented anew.<br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I view virTyped* as an associative array. So 2) is practically enabling<br>
multi value associative array. So I guess the first step would be to<br>
introduce new API (maybe set of APIs?) that are aware of this.<br></blockquote><div>I guess the first function to implement would be virTypedParamsGetNth() that is able to retrieve nth parameter with that name.<br></div><div>While this is easy to implement there are details remain:<br><ol><li>Should we implement a new set of virTypedParamsGetNth<TYPE> for each of the TYPE or should we start with just the 'String'?</li><li>Since virTypedParamsGet<TYPE> is just a virTypedParamsGetNth<TYPE> with N=0 should we make old functions just call new ones with N=0?<br></li></ol></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Then, virDomainMigrate*3() can just use this in the following way:<br>
<br>
a) when no "migrate_disk" is specified, the current behaviour is preserved<br>
<br>
b) when there are some disk selected for storage migration, since at<br>
this point we have virTyped* APIs to work with multivalue, we can get<br>
the array of disk targets to migrate and instruct qemu to just migrate them.<br>
<br>
Now, qemu has split storage and internal state migration into two<br>
streams. The first one is called NBD and libvirt selectively choses<br>
disks to migrate. For the other stream you don't have to care about.<br>
Look at qemuMigrationDriveMirror() and you'll see how libvirt instructs<br>
qemu to selectively migrate only some disks. The "migrate_disk" array<br>
would need to be propagated down here then.<br></blockquote><div>My concern is I would, most likely, have to backport these to our versions.<br></div><div> <br></div><div>Pavel<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Hopefully I haven't forgot nothing.<br>
<span class=""><font color="#888888"><br>
Michal<br>
</font></span></blockquote></div><br></div></div></div></div>