On May 10, 2013, at 1:10 PM, Laine Stump la...@laine.org wrote:
On 04/30/2013 02:12 PM, james robson wrote:
This patch adds functionality to allow libvirt to configure the
'native-tagged' and 'native-untagged' modes on openvswitch networks.
v2 changes:
Fix problems reported by Eric Blake
On Oct 29, 2012, at 5:50 PM, Laine Stump la...@laine.org wrote:
This patch resolves: https://bugzilla.redhat.com/show_bug.cgi?id=871201
If libvirt is restarted after updating the dnsmasq or radvd packages,
a subsequent virsh net-destroy will fail to kill the dnsmasq/radvd
process.
The
On Oct 30, 2012, at 12:49 PM, Laine Stump la...@laine.org wrote:
On 10/30/2012 09:13 AM, Kyle Mestery (kmestery) wrote:
ACK.
Thanks. I noticed during my final check that it was still failing make
syntax-check due to the syntax-check rule that prohibits calling
readlink not being specific
On Oct 23, 2012, at 12:37 PM, Laine Stump la...@laine.org wrote:
On 10/22/2012 05:30 PM, Laine Stump wrote:
This is an update of Kyle Mestery's patch series v3 by the same name:
https://www.redhat.com/archives/libvir-list/2012-October/msg00014.html
And I've just posted a new spin based on
On Oct 23, 2012, at 12:25 PM, Laine Stump la...@laine.org wrote:
From: Kyle Mestery kmest...@cisco.com
Add utility functions for Open vSwitch to both save
per-port data before a live migration, and restore the
per-port data after a live migration.
Signed-off-by: Kyle Mestery
On Oct 23, 2012, at 12:25 PM, Laine Stump la...@laine.org wrote:
From: Kyle Mestery kmest...@cisco.com
Add the ability for the Qemu V3 migration protocol to
include transporting network configuration. A generic
framework is proposed with this patch to allow for the
transfer of opaque data.
On Oct 23, 2012, at 12:25 PM, Laine Stump la...@laine.org wrote:
From: Kyle Mestery kmest...@cisco.com
Transport Open vSwitch per-port data during live
migration by using the utility functions
virNetDevOpenvswitchGetMigrateData() and
virNetDevOpenvswitchSetMigrateData().
Signed-off-by:
On Oct 11, 2012, at 4:36 PM, Kyle Mestery (kmestery) kmest...@cisco.com wrote:
On Oct 11, 2012, at 4:25 PM, Laine Stump la...@laine.org wrote:
On 10/11/2012 05:06 PM, Kyle Mestery (kmestery) wrote:
On Oct 1, 2012, at 10:18 AM, Kyle Mestery kmest...@cisco.com wrote:
This series of commits has
On Oct 22, 2012, at 9:16 AM, Laine Stump la...@laine.org wrote:
On 10/22/2012 09:41 AM, Kyle Mestery (kmestery) wrote:
On Oct 11, 2012, at 4:36 PM, Kyle Mestery (kmestery) kmest...@cisco.com
wrote:
On Oct 11, 2012, at 4:25 PM, Laine Stump la...@laine.org wrote:
On 10/11/2012 05:06 PM, Kyle
On Oct 22, 2012, at 4:21 PM, Laine Stump la...@laine.org wrote:
On 10/01/2012 11:18 AM, Kyle Mestery wrote:
Add the ability for the Qemu V3 migration protocol to
include transporting network configuration. A generic
framework is proposed with this patch to allow for the
transfer of opaque
On Oct 1, 2012, at 10:18 AM, Kyle Mestery kmest...@cisco.com wrote:
This series of commits has the end goal of allowing per-port data stored
in the Open vSwitch DB to be transported during live migration. This is
done by first providing a generic infrastructure for transporting network
data,
On Oct 11, 2012, at 4:25 PM, Laine Stump la...@laine.org wrote:
On 10/11/2012 05:06 PM, Kyle Mestery (kmestery) wrote:
On Oct 1, 2012, at 10:18 AM, Kyle Mestery kmest...@cisco.com wrote:
This series of commits has the end goal of allowing per-port data stored
in the Open vSwitch DB
On Oct 1, 2012, at 2:34 AM, Daniel P. Berrange wrote:
On Mon, Oct 01, 2012 at 03:48:32AM +, Kyle Mestery (kmestery) wrote:
On Sep 30, 2012, at 9:44 AM, Laine Stump wrote:
On 09/28/2012 03:58 PM, Kyle Mestery (kmestery) wrote:
As an example, an OpenFlow controller may have certain
On Oct 1, 2012, at 9:40 AM, Kyle Mestery (kmestery) wrote:
On Oct 1, 2012, at 2:34 AM, Daniel P. Berrange wrote:
On Mon, Oct 01, 2012 at 03:48:32AM +, Kyle Mestery (kmestery) wrote:
On Sep 30, 2012, at 9:44 AM, Laine Stump wrote:
On 09/28/2012 03:58 PM, Kyle Mestery (kmestery) wrote
On Sep 30, 2012, at 9:44 AM, Laine Stump wrote:
On 09/28/2012 03:58 PM, Kyle Mestery (kmestery) wrote:
As an example, an OpenFlow controller may have certain information about the
port, specific to this controller, which it may want to store with the port
itself on the
host. This especially
On Sep 28, 2012, at 11:42 AM, Daniel P. Berrange wrote:
On Fri, Sep 21, 2012 at 05:16:45PM -0400, Kyle Mestery wrote:
This series of commits has the end goal of allowing per-port data stored
in the Open vSwitch DB to be transported during live migration. This is
done by first providing a
On Sep 28, 2012, at 11:14 AM, Laine Stump wrote:
On 09/21/2012 05:16 PM, Kyle Mestery wrote:
Add the ability for the Qemu V3 migration protocol to
include transporting network configuration. A generic
framework is proposed with this patch to allow for the
transfer of opaque data.
I found an issue with this patch when migrating VMs without OVS
interfaces. I'm fixing that issue now, and will be posting V2 of this
series soon.
On Sep 14, 2012, at 11:38 AM, Kyle Mestery wrote:
This series of commits has the end goal of allowing per-port data stored
in the Open vSwitch DB
On Sep 14, 2012, at 9:04 PM, Laine Stump wrote:
On 09/14/2012 03:01 PM, Kyle Mestery wrote:
This series of commits has the end goal of allowing per-port data stored
in the Open vSwitch DB to be transported during live migration. This is
done by first providing a generic infrastructure for
On Sep 13, 2012, at 3:09 PM, Laine Stump wrote:
On 09/12/2012 11:08 PM, Kyle Mestery (kmestery) wrote:
Hi Laine:
I'm in the process of reworking this patch along the lines you and Daniel
have
provided input towards. I defined some helper functions in
virnetdevopenvswitch.c,
but when
On Sep 6, 2012, at 10:58 AM, Laine Stump wrote:
On 09/04/2012 04:35 PM, Kyle Mestery wrote:
Add the ability to migrate per-port data on Open vSwitch
ports during qemu live migration. A controller can use this
to store data relating to each port, and have it migrated
with the virtual machine
On Sep 6, 2012, at 12:35 AM, Daniel Veillard wrote:
On Tue, Sep 04, 2012 at 04:35:24PM -0400, Kyle Mestery wrote:
Add the ability to migrate per-port data on Open vSwitch
ports during qemu live migration. A controller can use this
to store data relating to each port, and have it migrated
with
On Sep 5, 2012, at 1:24 PM, Laine Stump wrote:
This fixes https://bugzilla.redhat.com/show_bug.cgi?id=852984
If a network or interface is configured to use Open vSwitch, but
ovs-vswitchd (the Open vSwitch database service) isn't running, the
ovs-vsctl add-port/del-port commands will hang
On Aug 31, 2012, at 9:09 AM, Daniel Veillard wrote:
On Fri, Aug 31, 2012 at 01:32:34PM +, Kyle Mestery (kmestery) wrote:
On Aug 30, 2012, at 10:23 PM, Daniel Veillard wrote:
On Thu, Aug 30, 2012 at 04:38:06PM -0400, Kyle Mestery wrote:
[...]
Still there is something which looks wrong
On Aug 30, 2012, at 10:23 PM, Daniel Veillard wrote:
On Thu, Aug 30, 2012 at 04:38:06PM -0400, Kyle Mestery wrote:
The introduction of the new VLAN code, along with the fix
from 5e465df6be8bcb00f0b4bff831e91f4042fae272, caused the
addition of OVS ports to fail with the following message:
On Aug 30, 2012, at 3:52 AM, Laine Stump wrote:
On 08/30/2012 01:32 AM, Eric Blake wrote:
[...]
That is, I think the real patch here would be simply this (untested)
version:
diff --git i/src/util/virnetdevopenvswitch.c
w/src/util/virnetdevopenvswitch.c
index b903ae4..e8b9f4a 100644
---
This fix is critical for the release tomorrow (0.10.1 I believe), as without
it, adding
ports to OVS bridges without a VLAN setup will fail.
Thanks,
Kyle
On Aug 30, 2012, at 1:53 PM, Kyle Mestery wrote:
The introduction of the new VLAN code, along with the fix
from
On Aug 30, 2012, at 3:31 PM, Eric Blake wrote:
On 08/30/2012 11:53 AM, Kyle Mestery wrote:
The introduction of the new VLAN code, along with the fix
from 5e465df6be8bcb00f0b4bff831e91f4042fae272, caused the
addition of OVS ports to fail with the following message:
ovs-vsctl:
On Aug 29, 2012, at 6:19 AM, Alex Jia wrote:
On 08/29/2012 06:43 PM, Laine Stump wrote:
This bug was revealed by the crash described in
https://bugzilla.redhat.com/show_bug.cgi?id=852383
The vlan info pointer sent to virNetDevOpenvswitchAddPort should never
be non-NULL unless there is
On Aug 29, 2012, at 9:49 AM, Kyle Mestery (kmestery) wrote:
On Aug 29, 2012, at 6:19 AM, Alex Jia wrote:
On 08/29/2012 06:43 PM, Laine Stump wrote:
This bug was revealed by the crash described in
https://bugzilla.redhat.com/show_bug.cgi?id=852383
The vlan info pointer sent
On Aug 17, 2012, at 1:18 PM, Laine Stump wrote:
On 08/17/2012 12:04 AM, Kyle Mestery wrote:
Add the ability to support VLAN tags for Open vSwitch
virtual port types. To accomplish this, modify
virNetDevOpenvswitchAddPort and
virNetDevTapCreateInBridgePort to take a virNetDevVlanPtr
argument.
On Aug 17, 2012, at 10:12 AM, Laine Stump wrote:
On 08/17/2012 12:04 AM, Kyle Mestery wrote:
Add the ability to support VLAN tags for Open vSwitch
virtual port types. To accomplish this, modify
virNetDevOpenvswitchAddPort and
virNetDevTapCreateInBridgePort to take a virNetDevVlanPtr
On Aug 15, 2012, at 12:47 PM, Laine Stump wrote:
On 08/14/2012 03:15 AM, Laine Stump wrote:
The purpose of these patches is to define a data type that can
properly describe an interface's vlan configuration (including
multiple vlans for trunking), provide XML parser and formatter to
translate
This looks good to me.
Acked-by: Kyle Mestery kmest...@cisco.com
On Aug 14, 2012, at 2:04 AM, Laine Stump wrote:
Both of these functions returned void, but it's convenient for them to
return a const char* of the char* that is passed in. This was you can
call the function and use the result
This looks good to me.
Acked-by: Kyle Mestery kmest...@cisco.com
On Aug 14, 2012, at 2:04 AM, Laine Stump wrote:
This function was overlooked when openvswitch support was
added. Fortunately it's only use for update-device, which is
relatively new and seldom-used.
---
This looks good to me.
Acked-by: Kyle Mestery kmest...@cisco.com
On Aug 14, 2012, at 2:04 AM, Laine Stump wrote:
virNetDevVPortProfile has (had) a type field that can be set to one of
several values, and a union of several structs, one for each
type. When a domain's interface object is of
This looks good to me.
Acked-by: Kyle Mestery kmest...@cisco.com
On Aug 14, 2012, at 2:04 AM, Laine Stump wrote:
virtPortProfile is now used by 4 different types of network devices
(NETWORK, BRIDGE, DIRECT, and HOSTDEV), and it's getting cumbersome to
replicate so much code in 4 different
Nice cleanup here, this looks good to me.
Acked-by: Kyle Mestery kmest...@cisco.com
On Aug 14, 2012, at 2:04 AM, Laine Stump wrote:
There was an error: label that simply did return ret, but ret was
defaulted to -1, and was never used other than setting it manually to
0 just before a
This looks good to me.
Acked-by: Kyle Mestery kmest...@cisco.com
On Aug 14, 2012, at 2:04 AM, Laine Stump wrote:
This patch adds three utility functions that operate on
virNetDevVPortProfile objects.
* virNetDevVPortProfileCheckComplete() - verifies that all attributes
required for the
This looks good to me.
Acked-by: Kyle Mestery kmest...@cisco.com
On Aug 14, 2012, at 2:04 AM, Laine Stump wrote:
This function has several calls to increase the buffer indent by 6,
then decrease it again, then increase, then decrease. Additionally,
there were several printfs that had 6
This looks good to me.
Acked-by: Kyle Mestery kmest...@cisco.com
On Aug 14, 2012, at 2:04 AM, Laine Stump wrote:
Until now, all attributes in a virtualport parameter list that were
acceptable for a particular type, were also required. There were no
optional attributes.
One of the aims of
This looks good to me, with some minor nits below.
Acked-by: Kyle Mestery kmest...@cisco.com
On Aug 14, 2012, at 2:04 AM, Laine Stump wrote:
One of the original ideas behind allowing a virtualport in an
interface definition as well as in the network definition *and*one
or more portgroups
Looks good to me.
Acked-by: Kyle Mestery kmest...@cisco.com
On Aug 14, 2012, at 2:10 AM, Laine Stump wrote:
I want to include this count in the xml output of networks, but
calling it connections in the XML sounds better than usageCount, and it
would be better if the name in the XML matched
Looks good.
Acked-by: Kyle Mestery kmest...@cisco.com
On Aug 14, 2012, at 2:10 AM, Laine Stump wrote:
A later patch will be adding a counter that will be
incremented/decremented each time an guest interface starts/stops
using a particular network. For this to work, all types of networks
Looks good to me.
Acked-by: Kyle Mestery kmest...@cisco.com
On Aug 14, 2012, at 2:10 AM, Laine Stump wrote:
This array was originally defined using the existing
virNetworkForwardIfDef, but that struct has a UsageCount field that
isn't used in the case of PFs. This patch just copies that
Looks good to me.
Acked-by: Kyle Mestery kmest...@cisco.com
On Aug 14, 2012, at 2:10 AM, Laine Stump wrote:
It may be useful for management applications to know which physical
network devices are in use by guests. This information is already
available in the network objects, but wasn't
Looks good to me.
Acked-by: Kyle Mestery kmest...@cisco.com
On Aug 14, 2012, at 2:10 AM, Laine Stump wrote:
Just as each physical device used by a network has a connections
counter, now each network has a connections counter which is
incremented once for each guest interface that connects
On Aug 13, 2012, at 12:04 AM, Laine Stump wrote:
On 08/10/2012 05:44 PM, Laine Stump wrote:
How about allowing multiple vlan tag='n' [trunk='yes|no']/ at the
toplevel? Then you could have:
vlan tag='42'/
in the simplest case, or:
vlan tag='42' trunk='yes'/
if you wanted a trunk
On Aug 9, 2012, at 3:14 PM, Laine Stump wrote:
On 08/08/2012 03:47 PM, Kyle Mestery wrote:
Add the ability to specify a vlantag parameter for bridge
networks with a virtualport type of openvswitch. This
allows for specifying the port is on a single VLAN, and
should receive untagged traffic
On Aug 9, 2012, at 4:23 AM, Daniel P. Berrange wrote:
On Wed, Aug 08, 2012 at 10:58:28PM -0400, Laine Stump wrote:
On 08/08/2012 12:30 PM, Kyle Mestery (kmestery) wrote:
On Aug 8, 2012, at 9:49 AM, Daniel P. Berrange wrote:
On Tue, Aug 07, 2012 at 03:50:20PM -0400, Laine Stump wrote:
Someone
On Aug 8, 2012, at 9:49 AM, Daniel P. Berrange wrote:
On Tue, Aug 07, 2012 at 03:50:20PM -0400, Laine Stump wrote:
Someone asked on IRC the other day about sending openvswitch per-port
data (normally stored in the switch) to the destination host during a
migration. I suggested maybe this could
On Aug 8, 2012, at 3:53 PM, dennis jenkins wrote:
How would one specify VLAN trunk mode with only one vlan tag present?
Actually, this is a deficiency with the model below, it isn't possible. I had
thought
of using vlantag=tag for access ports, and vlantrunk=tags for trunks,
but
was hoping
On Aug 8, 2012, at 7:06 PM, Ansis Atteka wrote:
On Wed, Aug 8, 2012 at 2:18 PM, Laine Stump la...@laine.org wrote:
On 08/08/2012 03:43 PM, Ansis Atteka wrote:
On Sat, Aug 4, 2012 at 10:16 PM, Laine Stump la...@laine.org wrote:
Although it's been possible (ever since openvswitch was added
I just looked at this series and it looks great to me Laine. I think the
new flexibility this series introduces will be really nice to have, and
it will make starting guests across hosts with differing network
types easier as well.
Thanks!
Kyle
On Aug 5, 2012, at 12:16 AM, Laine Stump wrote:
On Mar 1, 2012, at 11:51 PM, Ansis Atteka wrote:
This patch will allow OpenFlow controllers to identify which interface
belongs to a particular VM by using the Domain UUID.
ovs-vsctl get Interface vnet0 external_ids
{attached-mac=52:54:00:8C:55:2C,
55 matches
Mail list logo
