| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] XenLoop - Inter-VM Network Loopback
> 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.
Yes, basically call nf_register_hook on NF_IP_POST_ROUTING
> 2. Periodic scanning of XenStore entries: Why not callbacks?
One could...we just happened to implement it as a simple thread
to poll all active domains periodically in one thread and send out
announcements. This was not in the critical path.
> 3. Announcement messages: This is a layer 3 (IP) packet? I'd rather
> expected an ethertype.
No, its a layer 3 XenLoop-type packet, not IP -- the new protocol type
for exchanging control messages is registered at the same level as IP.
> 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?
I am not sure, I understood the question clearly, but I'll try. XenStore is
used here mainly for 3 things:
- For a guest to advertise its intent to participate in XenLoop to Domain 0
- For Domain 0 to read the guest's intent and announce it to other
interested guests
- For catching pre/post migration notices
This seems to work reasonably efficiently for now. One reason to have Domain0
participate in guest discovery is the limitation that one guest
cannot read another's
XenStore entries directly (with good reason) to discover co-resident
guests. There also
doesn't seem to be any notion yet of a machine-local broadcast message
(which may
have other drawbacks) or even a machine-local multicast group. As for
domain-arp,
there's the question of do we really want any random guest to be able
to discover any
other guest on the same machine? Using XenStore, with Domain 0 as
arbiter, provides
some level of control over who gets to see whom. As for why we
designed it this way,
because it happens to work cleanly...we tried initially to just
broadcast messages from
each guest, but didn't know how to contain the broadcasts to be machine-local.
> Still not through, therefore likely more to come.
Certainly. Thanks for the comments.
- Kartik
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home