On Tue, 2007-10-23 at 17:03 -0700, raghunathan srinivasan wrote:
> I saw a folder called drivers\xen\netfront.
> I guess it interacts with the backend driver. Do I make changes in it?
the answers are "yes, ", and "NO."
without the intend to kill all the joy in your venture: what you're
looking for is a customary firewall. with xen, i'd suggest to use linux
to do it. no coding required (except, maybe, tricky stuff in the
facebook-specific aspect, that depends). just grep the web for iptables.
the reason is because xen is not much about networking, as it's not
really about specific classes of devices, including network interfaces.
the VMM itself, as is all xen-specific things inside a linux guest, is
rather about raw resources: cpus, memory, interrupts, and only *very*
basic support in the area of domain intercommunciation.
your network interface is driven by dom0, the initial VM you find in on
the screen once you've booted your system. that is basically a linux
kernel with all the features, including a fairly comprehensive
firewalling solution, which does logging and filtering and part of it
even delegated to userland if you want to code custom tricks in a sane
fashion.
dom0 typically drives your network card. that's (typically) the eth0
device you see in your network setup. all traffic, including any
additional nonprivileged domain, passes dom0.
any other domain X gets a 'netfront' interface ethY, which is
conceptually connected to a 'netback' device vifX.Y via what you may
think of, in network lingo, as a virtual crossover cable:
dom0: eth0 <-- bridging/nat --> vif1.0 <--- x ---> domU: eth0
the trick is to get the firewall to filter packets as they pass from
eth0 to vifX.Y to the ethY inside the domain you want to restrict -- and
vice versa.
you'll maybe need to learn a little about topics like NAT and/or 802.1d
bridging, depending on your preferred network setup. then check out
network filtering on linux.
neither is a thing to learn about on xen-devel. for the xen-specific
parts of the equation above, i'd suggest to turn to the xen-users list,
as it hosts more people who are dealing with such issues on a regular
basis.
regards,
daniel
--
Daniel Stodden
LRR - Lehrstuhl für Rechnertechnik und Rechnerorganisation
Institut für Informatik der TU München D-85748 Garching
http://www.lrr.in.tum.de/~stodden mailto:stodden@xxxxxxxxxx
PGP Fingerprint: F5A4 1575 4C56 E26A 0B33 3D80 457E 82AE B0D8 735B
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|