That's why I've chosen to work purely with disk target at NBD level. We
have strong rules what characters can occur there. Moreover, it's fairly
easy to derive qemu disk ID from the target. Oh, and we require targets
to be unique throughout the domain. So I think it's the best option for
the extension you're planning.
Bad news is NBD is not enabled for tunnelled migration:
(src/qemu/qemu_migration.c, line 2635).
/* TODO support NBD for TUNNELLED migration */
if (flags & VIR_MIGRATE_TUNNELLED) {
VIR_WARN("NBD in tunnelled migration is currently not supported");
} else {
cookieFlags |= QEMU_MIGRATION_COOKIE_NBD;
priv->nbdPort = 0;
}
if (flags & VIR_MIGRATE_TUNNELLED) {
VIR_WARN("NBD in tunnelled migration is currently not supported");
} else {
cookieFlags |= QEMU_MIGRATION_COOKIE_NBD;
priv->nbdPort = 0;
}
So, we will need to implement this first for my code path, since all the migrations started by the Nova a tunnelled.
Hm.. what about this, introduce just this new function:
virTypedParamsGetArrayForKey(.., const char *key, ...)
Since we are using libvirt-python in nova I will have to change the way python bindings convert input `dict' to a TypedParams. For this, the `virPyDictToTypedParams' would have to be changed.
One cannot pass a multiple values with the same key in Python so `virPyDictToTypedParams' will have to translate dict(migrate_disk=[1,2,3]) into TypedParams {("migrate_disk", 1), ("migrate_disk", 2), ("migrate_disk", 3)}.
Pavel
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list