| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] XenLoop - Inter-VM Network Loopback
On Mon, 2008-02-11 at 21:51 -0500, Kartik Gopalan wrote:
> The analogy, though not perfect, is that a loopback carries traffic
> between different network endpoints within the same (virtual)
> machine -- the endpoints may be in different processes, not just
> the originator. XenLoop carries traffic between different network
> endpoints resident in the same "physical" machine but in
> different VMs. Your virtual crossover cable analogy is just how
> it happens to be currently implemented. One could implement
> XenLoop using other non-crossover-type designs, resulting in
> more VM crosstalk or less security, but functionally what it does
> would remain unchanged, which is to bypass the network
> datapath through Dom0.
I retreat. :) Just found that it does not reflect the difference to the
dom0 switch, which functionally qualifies as a loopback by the same
definition. And it's certainly not meant to question your work.
I've got a couple of additional questions and comments.
1. Netfilter setup: You're hooking into the output chain, just before
the packet is passed to the guest eth0? Did I get this right, or
something more esoteric? I'm asking because I'm definitely no netfilter
guru.
2. Periodic scanning of XenStore entries: Why not callbacks?
3. Announcement messages: This is a layer 3 (IP) packet? I'd rather
expected an ethertype.
4. Personally (this is dicussible) I don't like the XenStore/Message
*mixture* the directory is maintained with. I agree that due to the fact
that guests are limited to their private subtrees, maintenance of a
common directory is non-obvious but this is a defect in XenStore if the
directory should be there. XenStore is obvious, messages dissemination
as well. A dedicated resolution protocol (i.e. a domain-arp) appears
cleaner to me. I suppose there are issues in getting this to work
cleanly during migration (i.e. the need for invalidation messages before
leaving the host), or why did you choose this design?
Still not through, therefore likely more to come.
Thanks,
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
|
|
|
| |
|
Home