RE: Xend vnet support to be removed

RE: Xend vnet support to be removed

[Ian Pratt]

 
> BTW, you don't have any patches unapplied and outstanding, do 
> you?  If so, then now would be a good time to resend them, 
> because they've been missed if so!

If it needs patches to work against the 2.6.14 tree in linux-2.6-xen.hg
then it would be good to post those otherwise it'll get broken when that
code is checked in (possibly this week).

Ian

Re: Xend vnet support to be removed

[Mike Wray]

Ian Pratt wrote:
>  
> 
>>BTW, you don't have any patches unapplied and outstanding, do 
>>you?  If so, then now would be a good time to resend them, 
>>because they've been missed if so!
> 
> 
> If it needs patches to work against the 2.6.14 tree in linux-2.6-xen.hg
> then it would be good to post those otherwise it'll get broken when that
> code is checked in (possibly this week).
> 

The code seems to compile OK against the 2.6.14 tree.
I'll post a patch for the latest version as soon as I've done
a bit more testing.

Mike

Re: Xend vnet support to be removed

[Mike Wray]

James Harper wrote:
> Based on the description from your documentation, it sounds like the
> guts of vnets could be done with 802.1q vlan trunking and bridging. No
> extra code required. I'm already doing this now, where each xen server
> has two physical interfaces (one for AoE, and one for domu network
> access). I can provide some more information on 802.1q vlan trunking if
> anyone is interested.
> 
> I'm basing all of my knowledge of vnets on a brief skim of the
> documentation in your email below, so feel free to enlighten me as to
> why they are different :)

In terms of abstract functionality they are very similar,
but there are important practical differences.
As far as I am aware, use of vlans requires that you have vlan-capable
switches in your network, and that you can configure them. Ordinary mortals
can't usually configure their network's vlan switches (if it has them).
Vnets don't require any assistance from the network,
and can be tunneled to remote subnets or through firewalls.
This is because vnets tunnel ethernet frames inside IP packets, which are
then routed normally, rather than using a modified ethernet frame like the
802.1q vlan header.

So a vnet can be created by anyone and its connectivity can span an
arbitrary piece of the IP network - not something you can do with vlans
It's also possible to run completely independent vnet infrastructures on the
same network simply by using different multicast addresses.
A new vnet can be dynamically created by configuring its endpoints, without
configuring anything in the network.

Vlan packets are limited to a 12-bit vlan id and have no support for
authentication or encryption. Vnets support 128-bit vnet ids and can
support authentication and encryption, currently using IPSEC.

Mike

RE: Xend vnet support to be removed

[James Harper]

Based on the description from your documentation, it sounds like the
guts of vnets could be done with 802.1q vlan trunking and bridging. No
extra code required. I'm already doing this now, where each xen server
has two physical interfaces (one for AoE, and one for domu network
access). I can provide some more information on 802.1q vlan trunking if
anyone is interested.

I'm basing all of my knowledge of vnets on a brief skim of the
documentation in your email below, so feel free to enlighten me as to
why they are different :)

Thanks

James

> -----Original Message-----
> From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-
> bounces@lists.xensource.com] On Behalf Of Mike Wray
> Sent: Tuesday, 13 December 2005 00:48
> To: Ewan Mellor
> Cc: Xen-devel
> Subject: Re: [Xen-devel] Xend vnet support to be removed
> 
> Ewan Mellor wrote:
> > On Mon, Dec 12, 2005 at 08:45:00AM +0000, Mike Wray wrote:
> >
> >
> >>Ewan Mellor wrote:
> >>
> >>>Unless someone speaks up, Xend vnet support will be removed.  It is
> broken,
> >>>unused, and unloved (as far as I know).  This is the xm vnet-list,
> >>>vnet-create, and vnet-delete commands, as well as all the Xend
support
> >>>behind
> >>>that (XendVnet.py, SrvVnetDir.py, plus plumbing in xm/main.py and
> >>>XendClient.py).
> >>>
> >>>Cheers,
> >>>
> >>>Ewan.
> >>
> >>As the developer of the vnet count I'm speaking up for this code.
> >>As far as I am aware it is neither broken nor unused, and I
> >>have recently submitted patches to this list updating the code.
> >>The code is in active development and I will be continuing to
maintain
> it.
> >>So please don't remove it.
> >
> >
> > That's fine.  It seems like there are a number of people using it or
> wishing
> > to, so it will stay in place.
> >
> > I asked because there was recently an effort to bring the
documentation
> up to
> > date, by various members of the Xen community, and yet the
documentation
> for
> > Xen 3.0 went out with no mention of the vnet support, because no-one
> seemed to
> > know how to use it properly.
> >
> > Perhaps you could write a few lines for us to go into the user
> documentation?
> > A number of people have said that that the vnet support is useful,
so it
> would
> > be good if we could get it documented, and spread the news!
> >
> > BTW, you don't have any patches unapplied and outstanding, do you?
If
> so,
> > then now would be a good time to resend them, because they've been
> missed if
> > so!
> >
> > Thanks,
> >
> > Ewan.
> 
> I think all the patches I've sent so far have been applied - I've got
> some more changes I'm working on, but they're not quite ready to post
> yet.
> 
> There's some brief documentation below (extracted from the doc
directory
> in the
> vnet source).  What format would you prefer for more extensive
> documentation?
> 
> 0) Introduction
> ---------------
> 
> Vnets provide virtual private LANs for virtual machines.
> This is done using bridging and multipoint tunneling. A virtual
interface
> on a vnet can only see other interfaces on the same vnet - it cannot
> see the real network, and the real network cannot see it either.
> 
> Virtual interfaces on the same vnet can be on the same machine
> or on different machines, they can still talk. The hosting machines
> can even be on different subnets if you run vnetd to forward,
> or have multicast routing enabled.
> 
> 
> 1) Installing vnet support
> --------------------------
> 
> Assuming the code has been installed (make install in the parent
> directory),
> configure xend to use 'network-vnet' instead of the default 'network'
to
> start up networking. This just loads the vnet module when networking
> starts.
> 
> In /etc/xend/xend-config.sxp:
> 
> Configure the network script:
> 
> (network-script        network-vnet)
> 
> Restart xend.
> 
> Alternatively insert the vnet module using vnet-insert,
> preferably before xend starts.
> 
> 2) Creating vnets
> -----------------
> 
> Xend already implements commands to add/remove vnets and
> bridge to them. To add a vnet use
> 
> xm vnet-create <vnet config file>
> 
> For example, if vnet97.sxp contains:
> 
> (vnet (id 97) (bridge vnet97) (vnetif vnif97) (security none))
> 
> do
> 
> xm vnet-create vnet97.sxp
> 
> This will define a vnet with id 97 and no security. The bridge for the
> vnet is called vnet97 and the virtual interface for it is vnif97.
> To add an interface on a vm to this vnet simply set its bridge to
vnet97
> in its configuration.
> 
> In Python:
> 
> vif="bridge=vnet97"
> 
> In sxp:
> 
> (dev (vif (mac aa:00:00:01:02:03) (bridge vnet97)))
> 
> At the moment you will also have to reduce the MTU of the
corresponding
> device in the domain (because of the tunneling). For example, for eth0
use
> 
> ifconfig eth0 mtu 1400
> 
> or, better, put
> 
> MTU=1400
> 
> in /etc/sysconfig/network-scripts/ifcfg-eth0. You may also have to
change
> or remove
> cached config files for eth0 under /etc/sysconfig/networking.
> 
> Once configured, vnets are persistent in the xend database.
> To remove a vnet use
> 
> xm vnet-delete <vnet id>
> 
> To list vnets use
> 
> xm vnet-list
> 
> To get information on one or more vnet ids use
> 
> xm vnet-list <vnet id>...
> 
> 3) Troubleshooting
> ------------------
> 
> The vnet module should appear in 'lsmod'.
> If a vnet has been configured it should appear in the output of 'xm
vnet-
> list'.
> Its bridge and interface should appear in 'ifconfig'.
> It should also show in 'brctl show', with its attached interfaces.
> 
> You can 'see into' a vnet from dom0 if you put an IP address on the
> bridge.
> For example, if you have vnet97 with a vm with ip addr 10.0.0.12 on
it,
> then
> 
> ifconfig vnet97 10.0.0.20 up
> 
> should let you ping 10.0.0.12 via the vnet97 bridge.
> 
> 
> Mike
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

Re: Xend vnet support to be removed

[Ewan Mellor]

On Mon, Dec 12, 2005 at 01:48:20PM +0000, Mike Wray wrote:

> There's some brief documentation below (extracted from the doc directory in 
> the
> vnet source).  What format would you prefer for more extensive 
> documentation?

The User's Manual source is in LaTeX, and in docs/src/user.tex.  A patch
against that (or a cut-and-paste chapter) would be best.  Thanks,

Ewan.

Re: Xend vnet support to be removed

[Mike Wray]

Ewan Mellor wrote:
> On Mon, Dec 12, 2005 at 08:45:00AM +0000, Mike Wray wrote:
> 
> 
>>Ewan Mellor wrote:
>>
>>>Unless someone speaks up, Xend vnet support will be removed.  It is broken,
>>>unused, and unloved (as far as I know).  This is the xm vnet-list,
>>>vnet-create, and vnet-delete commands, as well as all the Xend support 
>>>behind
>>>that (XendVnet.py, SrvVnetDir.py, plus plumbing in xm/main.py and
>>>XendClient.py).
>>>
>>>Cheers,
>>>
>>>Ewan.
>>
>>As the developer of the vnet count I'm speaking up for this code.
>>As far as I am aware it is neither broken nor unused, and I
>>have recently submitted patches to this list updating the code.
>>The code is in active development and I will be continuing to maintain it.
>>So please don't remove it.
> 
> 
> That's fine.  It seems like there are a number of people using it or wishing
> to, so it will stay in place.
> 
> I asked because there was recently an effort to bring the documentation up to
> date, by various members of the Xen community, and yet the documentation for
> Xen 3.0 went out with no mention of the vnet support, because no-one seemed to
> know how to use it properly.
> 
> Perhaps you could write a few lines for us to go into the user documentation?
> A number of people have said that that the vnet support is useful, so it would
> be good if we could get it documented, and spread the news!
> 
> BTW, you don't have any patches unapplied and outstanding, do you?  If so,
> then now would be a good time to resend them, because they've been missed if
> so!
> 
> Thanks,
> 
> Ewan.

I think all the patches I've sent so far have been applied - I've got
some more changes I'm working on, but they're not quite ready to post
yet.

There's some brief documentation below (extracted from the doc directory in the
vnet source).  What format would you prefer for more extensive documentation?

0) Introduction
---------------

Vnets provide virtual private LANs for virtual machines.
This is done using bridging and multipoint tunneling. A virtual interface
on a vnet can only see other interfaces on the same vnet - it cannot
see the real network, and the real network cannot see it either.

Virtual interfaces on the same vnet can be on the same machine
or on different machines, they can still talk. The hosting machines
can even be on different subnets if you run vnetd to forward,
or have multicast routing enabled.


1) Installing vnet support
--------------------------

Assuming the code has been installed (make install in the parent directory),
configure xend to use 'network-vnet' instead of the default 'network' to
start up networking. This just loads the vnet module when networking starts.

In /etc/xend/xend-config.sxp:

Configure the network script:

(network-script        network-vnet)

Restart xend.

Alternatively insert the vnet module using vnet-insert,
preferably before xend starts.

2) Creating vnets
-----------------

Xend already implements commands to add/remove vnets and
bridge to them. To add a vnet use

xm vnet-create <vnet config file>

For example, if vnet97.sxp contains:

(vnet (id 97) (bridge vnet97) (vnetif vnif97) (security none))

do

xm vnet-create vnet97.sxp

This will define a vnet with id 97 and no security. The bridge for the
vnet is called vnet97 and the virtual interface for it is vnif97.
To add an interface on a vm to this vnet simply set its bridge to vnet97
in its configuration.

In Python:

vif="bridge=vnet97"

In sxp:

(dev (vif (mac aa:00:00:01:02:03) (bridge vnet97)))

At the moment you will also have to reduce the MTU of the corresponding
device in the domain (because of the tunneling). For example, for eth0 use

ifconfig eth0 mtu 1400

or, better, put

MTU=1400

in /etc/sysconfig/network-scripts/ifcfg-eth0. You may also have to change or remove
cached config files for eth0 under /etc/sysconfig/networking.

Once configured, vnets are persistent in the xend database.
To remove a vnet use

xm vnet-delete <vnet id>

To list vnets use

xm vnet-list

To get information on one or more vnet ids use

xm vnet-list <vnet id>...

3) Troubleshooting
------------------

The vnet module should appear in 'lsmod'.
If a vnet has been configured it should appear in the output of 'xm vnet-list'.
Its bridge and interface should appear in 'ifconfig'.
It should also show in 'brctl show', with its attached interfaces.

You can 'see into' a vnet from dom0 if you put an IP address on the bridge.
For example, if you have vnet97 with a vm with ip addr 10.0.0.12 on it,
then

ifconfig vnet97 10.0.0.20 up

should let you ping 10.0.0.12 via the vnet97 bridge.


Mike

Re: Xend vnet support to be removed

[Ewan Mellor]

On Mon, Dec 12, 2005 at 08:45:00AM +0000, Mike Wray wrote:

> Ewan Mellor wrote:
> >Unless someone speaks up, Xend vnet support will be removed.  It is broken,
> >unused, and unloved (as far as I know).  This is the xm vnet-list,
> >vnet-create, and vnet-delete commands, as well as all the Xend support 
> >behind
> >that (XendVnet.py, SrvVnetDir.py, plus plumbing in xm/main.py and
> >XendClient.py).
> >
> >Cheers,
> >
> >Ewan.
> 
> As the developer of the vnet count I'm speaking up for this code.
> As far as I am aware it is neither broken nor unused, and I
> have recently submitted patches to this list updating the code.
> The code is in active development and I will be continuing to maintain it.
> So please don't remove it.

That's fine.  It seems like there are a number of people using it or wishing
to, so it will stay in place.

I asked because there was recently an effort to bring the documentation up to
date, by various members of the Xen community, and yet the documentation for
Xen 3.0 went out with no mention of the vnet support, because no-one seemed to
know how to use it properly.

Perhaps you could write a few lines for us to go into the user documentation?
A number of people have said that that the vnet support is useful, so it would
be good if we could get it documented, and spread the news!

BTW, you don't have any patches unapplied and outstanding, do you?  If so,
then now would be a good time to resend them, because they've been missed if
so!

Thanks,

Ewan.

Re: Xend vnet support to be removed

[Mike Wray]

Ewan Mellor wrote:
> Unless someone speaks up, Xend vnet support will be removed.  It is broken,
> unused, and unloved (as far as I know).  This is the xm vnet-list,
> vnet-create, and vnet-delete commands, as well as all the Xend support behind
> that (XendVnet.py, SrvVnetDir.py, plus plumbing in xm/main.py and
> XendClient.py).
> 
> Cheers,
> 
> Ewan.

As the developer of the vnet count I'm speaking up for this code.
As far as I am aware it is neither broken nor unused, and I
have recently submitted patches to this list updating the code.
The code is in active development and I will be continuing to maintain it.
So please don't remove it.

Mike

Re: Xend vnet support to be removed

[Sean Dague]

[-- Attachment #1.1: Type: text/plain, Size: 1996 bytes --]

On Fri, Dec 09, 2005 at 10:33:33AM -0600, Tim Freeman wrote:
> On Fri, 9 Dec 2005 16:20:47 -0000
> "Ian Pratt" <m+Ian.Pratt@cl.cam.ac.uk> wrote:
> 
> > > Unless someone speaks up, Xend vnet support will be removed.  
> > > It is broken, unused, and unloved (as far as I know).  This 
> > > is the xm vnet-list, vnet-create, and vnet-delete commands, 
> > > as well as all the Xend support behind that (XendVnet.py, 
> > > SrvVnetDir.py, plus plumbing in xm/main.py and XendClient.py).
> > 
> > That's a shame, but unless someone steps up to maintain it then I'm
> > agree it makes sense to pull it. 
> > 
> > We should certianly hide it from the usage message. Perhaps we need a
> > special environment variable or command line option to un-hide broken or
> > under-development features? I think this would be generally useful.
> 
> We'd appreciate this approach if it is not hard to do. vnet is a useful
> technology, I'd hate to see it less accessible. 

Tim, 

Are you using it in Xen 3.0?  Given the lack of checkins since Sept, it
wasn't obvious if it still worked.

I think that features that hidden are bad for everyone though, as no one
maintaining the code knows if it works or not, or knows what to do to avoid
breaking when changing other code.  It will just end up in bit rot.

It should either be documented, or removed IMHO.  Either are good choices.
The first one does need a volunteer that understands it though, and someone
to step up and maintain it.

	-Sean

-- 
__________________________________________________________________

Sean Dague                                       Mid-Hudson Valley
sean at dague dot net                            Linux Users Group
http://dague.net                                 http://mhvlug.org

There is no silver bullet.  Plus, werewolves make better neighbors
than zombies, and they tend to keep the vampire population down.
__________________________________________________________________

[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: Xend vnet support to be removed

[Ewan Mellor]

On Fri, Dec 09, 2005 at 10:33:33AM -0600, Tim Freeman wrote:

> On Fri, 9 Dec 2005 16:20:47 -0000
> "Ian Pratt" <m+Ian.Pratt@cl.cam.ac.uk> wrote:
> 
> > > Unless someone speaks up, Xend vnet support will be removed.  
> > > It is broken, unused, and unloved (as far as I know).  This 
> > > is the xm vnet-list, vnet-create, and vnet-delete commands, 
> > > as well as all the Xend support behind that (XendVnet.py, 
> > > SrvVnetDir.py, plus plumbing in xm/main.py and XendClient.py).
> > 
> > That's a shame, but unless someone steps up to maintain it then I'm
> > agree it makes sense to pull it. 
> > 
> > We should certianly hide it from the usage message. Perhaps we need a
> > special environment variable or command line option to un-hide broken or
> > under-development features? I think this would be generally useful.
> 
> We'd appreciate this approach if it is not hard to do. vnet is a useful
> technology, I'd hate to see it less accessible. 

Well if you are using it, then it can stay in there, by all means.  If you
wanted to volunteer to document it and fix it if it needs fixing, then that
would be even better ;-)

Thanks,

Ewan.

Re: Xend vnet support to be removed

[Tim Freeman]

On Fri, 9 Dec 2005 16:20:47 -0000
"Ian Pratt" <m+Ian.Pratt@cl.cam.ac.uk> wrote:

> > Unless someone speaks up, Xend vnet support will be removed.  
> > It is broken, unused, and unloved (as far as I know).  This 
> > is the xm vnet-list, vnet-create, and vnet-delete commands, 
> > as well as all the Xend support behind that (XendVnet.py, 
> > SrvVnetDir.py, plus plumbing in xm/main.py and XendClient.py).
> 
> That's a shame, but unless someone steps up to maintain it then I'm
> agree it makes sense to pull it. 
> 
> We should certianly hide it from the usage message. Perhaps we need a
> special environment variable or command line option to un-hide broken or
> under-development features? I think this would be generally useful.

We'd appreciate this approach if it is not hard to do. vnet is a useful
technology, I'd hate to see it less accessible. 

Thanks,
Tim 

RE: Xend vnet support to be removed

[Ian Pratt]

> Unless someone speaks up, Xend vnet support will be removed.  
> It is broken, unused, and unloved (as far as I know).  This 
> is the xm vnet-list, vnet-create, and vnet-delete commands, 
> as well as all the Xend support behind that (XendVnet.py, 
> SrvVnetDir.py, plus plumbing in xm/main.py and XendClient.py).

That's a shame, but unless someone steps up to maintain it then I'm
agree it makes sense to pull it. 

We should certianly hide it from the usage message. Perhaps we need a
special environment variable or command line option to un-hide broken or
under-development features? I think this would be generally useful.

Ian

Xend vnet support to be removed

[Ewan Mellor]

Unless someone speaks up, Xend vnet support will be removed.  It is broken,
unused, and unloved (as far as I know).  This is the xm vnet-list,
vnet-create, and vnet-delete commands, as well as all the Xend support behind
that (XendVnet.py, SrvVnetDir.py, plus plumbing in xm/main.py and
XendClient.py).

Cheers,

Ewan.