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

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&lt;stefanb(a)us.ibm.com&gt; > Signed-off-by: Gerhard Stenzel&lt;gerhard.stenzel(a)de.ibm.com&gt; > @@ -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)?

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