[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] network idea



> I'm just looking at this now. I think that to do this I need to comment
> out anything bridge related in
> linux-2.4.26-xen-sparse/arch/xen/drivers/netif/backend/interface.c
> so that xen doesn't do any bridging stuff, and then hook into xend so
> that it can call my scripts when the netif_fe_interface_status_changed
> events occur. It's the second bit I'm having trouble with... where
> should that hook into? I can see where xend might sends such events...
> maybe it doesn't have visibility to receiving them??? 

James, 

The bridge stuff should be moving out of backend/interface.c and
into a xend invoked script any day now  -- stay tuned ;-)

> By taking the bridge stuff out of xen and putting it all in userland, it
> means that we can route packets or bridge interfaces or completely
> isolate them if desired. My reasons for doing it is that my server has 3
> network cards, but any domain is only going to connect to 1 or 2 of
> them, but not necessarily the same 1 or 2 as other domains.

We need to put our thinking caps on and figure out how we want
domain bridging/networking/firewalling to work from a control
software point of view, particularly with respect to domain
migration and such like.

Ian


 
> Any suggestions?
> 
> Thanks
> 
> James
> 
> > -----Original Message-----
> > From: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx [mailto:xen-devel-
> > admin@xxxxxxxxxxxxxxxxxxxxx] On Behalf Of James Harper
> > Sent: Tuesday, 22 June 2004 20:43
> > To: xen-devel@xxxxxxxxxxxxxxxxxxxxx
> > Subject: [Xen-devel] network idea
> > 
> > In order to make xend a bit more flexible about what it does with
> > networking, would it be possible to have it just call out scripts like
> > pppd (on debian at least) does.
> > 
> > The idea would be /etc/xend/netup.d and /etc/xend/netdown.d
> directories
> > in which scripts are called with 'runparts' when a network interface
> on
> > a domain starts or stops (or similar hooks). To be useful the scripts
> > would need at least the following args passed in:
> > vmid - id of vm
> > index - network interface no
> > netif - eg vif1.3
> > name - name of vm
> > 
> > I know very little about python, but a fair bit about linux systems
> > programming in general and so would be happy to tackle this myself
> > unless it's already in progress or is a stupid idea...
> > 
> > Thanks
> > 
> > James
> > 
> > 
> > 
> > -------------------------------------------------------
> > This SF.Net email sponsored by Black Hat Briefings & Training.
> > Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> > digital self defense, top technical experts, no vendor pitches,
> > unmatched networking opportunities. Visit www.blackhat.com
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@xxxxxxxxxxxxxxxxxxxxx
> > https://lists.sourceforge.net/lists/listinfo/xen-devel
> 
> 
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
> digital self defense, top technical experts, no vendor pitches, 
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxxxx
> https://lists.sourceforge.net/lists/listinfo/xen-devel
 -=- MIME -=- 
I'm just looking at this now. I think that to do this I need to comment
out anything bridge related in
linux-2.4.26-xen-sparse/arch/xen/drivers/netif/backend/interface.c
so that xen doesn't do any bridging stuff, and then hook into xend so
that it can call my scripts when the netif_fe_interface_status_changed
events occur. It's the second bit I'm having trouble with... where
should that hook into? I can see where xend might sends such events...
maybe it doesn't have visibility to receiving them???

By taking the bridge stuff out of xen and putting it all in userland, it
means that we can route packets or bridge interfaces or completely
isolate them if desired. My reasons for doing it is that my server has 3
network cards, but any domain is only going to connect to 1 or 2 of
them, but not necessarily the same 1 or 2 as other domains.

Any suggestions?

Thanks

James

> -----Original Message-----
> From: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx [mailto:xen-devel-
> admin@xxxxxxxxxxxxxxxxxxxxx] On Behalf Of James Harper
> Sent: Tuesday, 22 June 2004 20:43
> To: xen-devel@xxxxxxxxxxxxxxxxxxxxx
> Subject: [Xen-devel] network idea
>=20
> In order to make xend a bit more flexible about what it does with
> networking, would it be possible to have it just call out scripts like
> pppd (on debian at least) does.
>=20
> The idea would be /etc/xend/netup.d and /etc/xend/netdown.d
directories
> in which scripts are called with 'runparts' when a network interface
on
> a domain starts or stops (or similar hooks). To be useful the scripts
> would need at least the following args passed in:
> vmid - id of vm
> index - network interface no
> netif - eg vif1.3
> name - name of vm
>=20
> I know very little about python, but a fair bit about linux systems
> programming in general and so would be happy to tackle this myself
> unless it's already in progress or is a stupid idea...
>=20
> Thanks
>=20
> James
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> digital self defense, top technical experts, no vendor pitches,
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxxxx
> https://lists.sourceforge.net/lists/listinfo/xen-devel


-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel



-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.