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. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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. __________________________________________________________________ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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
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. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 Xendsupport> >>>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 tomaintain> 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 thedocumentation> up to > > date, by various members of the Xen community, and yet thedocumentation> 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 docdirectory> 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 virtualinterface> 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 tovnet97> 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 thecorresponding> device in the domain (because of the tunneling). For example, for eth0use> > ifconfig eth0 mtu 1400 > > or, better, put > > MTU=1400 > > in /etc/sysconfig/network-scripts/ifcfg-eth0. You may also have tochange> 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 ''xmvnet-> 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 onit,> 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_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel