Re: [libvirt] [PATCH 1/1] Initial POC of port profile id support
On Tue, 30 Mar 2010, David Allan wrote:
Date: Tue, 30 Mar 2010 17:30:56 -0400
From: David Allan <dallan(a)redhat.com>
To: libvir-list(a)redhat.com
Subject: [libvirt] [PATCH 1/1] Initial POC of port profile id support
---
docs/schemas/domain.rng | 8 ++++++++
src/conf/domain_conf.c | 12 ++++++++++++
src/conf/domain_conf.h | 1 +
src/libvirt_private.syms | 3 +++
src/qemu/qemu_conf.c | 12 ++++++++++++
src/util/macvtap.c | 13 +++++++++++++
src/util/macvtap.h | 4 ++++
7 files changed, 53 insertions(+), 0 deletions(-)
diff --git a/docs/schemas/domain.rng b/docs/schemas/domain.rng
index d804301..5917f60 100644
--- a/docs/schemas/domain.rng
+++ b/docs/schemas/domain.rng
@@ -794,6 +794,11 @@
<ref name="bridgeMode"/>
</attribute>
</optional>
+ <optional>
+ <attribute name="profileid">
+ <ref name="profileID"/>
+ </attribute>
+ </optional>
<empty/>
</element>
<ref name="interface-options"/>
This is a good proposal. We need it to correctly configure the
guests with VEPA mode. The profile-ID is required for the VEPA mode as
per IEEE 802.1Qbg proposal, however, we can use it with bridging mode as
well. How do we associate it with bridging mode if so desired?
@@ -1647,6 +1652,9 @@
<param name="pattern">(vepa|bridge|private)</param>
</data>
</define>
+ <define name="profileID">
+ <data type="string"/>
+ </define>
<define name="addrMAC">
The profile-ID, as per the TLV described comprises of the following
fields: VSI Manager, VSI instance ID, VSI type, VSI type version.
Though I agree libvirt need not know how to parse it or define the
fields.
+ /* Failure here is equivalent to the failure to plug in a physical
+ * network port.
+ *
+ * If this operation is non-blocking we will have a race between
+ * the VM starting and the interface coming up.
+ *
+ * If any of the subsequent operations fail, will we need to
+ * unwind the sending of the port profile id? */
+ sendPortProfileId(net->data.direct.linkdev,
+ net->data.direct.mode,
+ net->data.direct.profileid);
+
This is good. The VSI Discovery and Configuration protocol(VDP) will need
to be run between the bridge and the KVM host. The VDP daemon then
receives the profile details along with the MAC/VLAN settings for the
interface and initiates the VDP on its behalf with the switch.
A synchronous wait for the VDP to successfully associate the MAC/VLAN
with the switch seems the simplest unless the MACVTAP is configured in
'no carrier' state in the guest (Can that be done?). Otherwise the VM
might start transmitting and loose packets while the VDP completes its
registration. Blocking mode also makes error percolation easier as well.
Vivek
# define MACVTAP_MODE_PRIVATE_STR "private"
--
1.7.0.1
--
libvir-list mailing list
libvir-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
__
Vivek Kashyap
Linux Technology Center, IBM