[libvirt] [PATCH] 802.1Qbg: use pre-associate state at beginning of incoming migration

[Stefan Berger]

On 11/23/2010 03:50 PM, Eric Blake wrote:
> On 11/18/2010 08:31 AM, Stefan Berger wrote:
>
> [apologies for letting this delay a week]
>
>> This patch introduces the usage of the pre-associate state of the IEEE
>> 802.1Qbg standard on incoming VM migration on the target host. It is in
>> response to bugzilla entry 632750.
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=632750
>>
>> For being able to differentiate the exact reason as to why a macvtap
>> device is being created, either due to a VM creation or an incoming VM
>> migration, I needed to pass that reason as a parameter from wherever
>> qemudStartVMDaemon is being called in order to determine whether to send
>> an ASSOCIATE (VM creation) or a PRE-ASSOCIATE (incoming VM migration)
>> towards lldpad.
>>
>> I am also fixing problem with the virsh domainxml-to-native call on the
>> way.
>>
>> Gerhard successfully tested the patch with a recent blade network
>> 802.1Qbg-compliant switch.
>>
>> The patch should not have any side-effects on the 802.1Qbh support in
>> libvirt, but Scott (cc'ed) may want to verify this.
>>
>> Signed-off-by: Stefan Berger<stefanb at us.ibm.com>
>> Signed-off-by: Gerhard Stenzel<gerhard.stenzel at de.ibm.com>
>> @@ -3951,7 +3953,8 @@ int qemudBuildCommandLine(virConnectPtr
>>                             int **vmfds,
>>                             int *nvmfds,
>>                             const char *migrateFrom,
>> -                          virDomainSnapshotObjPtr current_snapshot)
>> +                          virDomainSnapshotObjPtr current_snapshot,
>> +                          enum vmOperation vmop)
> Oh joy - a merge conflict with my virCommand stuff.  If you push first,
> then I get to pick up the pieces :)
>
>> @@ -11844,6 +11851,41 @@ cleanup:
>>       return ret;
>>   }
>>
>> +static void
>> +qemudVPAssociatePortProfiles(virDomainDefPtr def) {
>> +    int i;
>> +    int last_good_net = -1;
>> +    virDomainNetDefPtr net;
>> +
>> +    for (i = 0; i<   def->nnets; i++) {
>> +        net = def->nets[i];
>> +        if (net->type == VIR_DOMAIN_NET_TYPE_DIRECT) {
>> +            if (vpAssociatePortProfileId(net->ifname,
>> +                                         net->mac,
>> +                                         net->data.direct.linkdev,
>> +&net->data.direct.virtPortProfile,
>> +                                         def->uuid,
>> +                                         VM_OP_MIGRATE_IN_FINISH) != 0)
>> +                goto err_exit;
>> +        }
>> +        last_good_net = i;
>> +    }
>> +
>> +    return;
>> +
>> +err_exit:
>> +    for (i = 0; i<   last_good_net; i++) {
> Should this loop be from (last_good_net,0] instead of [0,last_good_net)
> (that is, inverse of creation order)?
>
The order of the teardown doesn't matter from what I can see.
>> Index: libvirt-acl/src/util/macvtap.c
>> ===================================================================
>> --- libvirt-acl.orig/src/util/macvtap.c
>> +++ libvirt-acl/src/util/macvtap.c
>> @@ -77,9 +77,22 @@
>>   # define LLDPAD_PID_FILE  "/var/run/lldpad.pid"
>>
>>
>> +static const char *vmOpStr[] = {
>> +    [VM_OP_CREATE] = "create",
>> +    [VM_OP_SAVE] = "save",
>> +    [VM_OP_RESTORE] = "restore",
>> +    [VM_OP_DESTROY] = "destroy",
>> +    [VM_OP_MIGRATE_OUT] = "migrate out",
>> +    [VM_OP_MIGRATE_IN_START] = "migrate in start",
>> +    [VM_OP_MIGRATE_IN_FINISH] = "migrate in finish",
>> +    [VM_OP_NO_OP] = "no-op"
> This seems like it would better be done via VIR_ENUM_DECL and VIR_ENUM_IMPL?
>
Yes, I'll convert it and repost.

     Stefan