From: Nivedita Singhvi <niv@us.ibm.com>
To: Anthony Liguori <aliguori@us.ibm.com>
Cc: Lon Hohberger <lhh@redhat.com>, xen-devel@lists.xensource.com
Subject: Re: RFC: "local" communications
Date: Wed, 15 Jun 2005 14:31:10 -0700 [thread overview]
Message-ID: <42B09E1E.3060709@us.ibm.com> (raw)
In-Reply-To: <42B08E8A.9090609@us.ibm.com>
Anthony Liguori wrote:
> Rik van Riel wrote:
>
>> Hi,
>>
>> When combining clustering with cluster storage, the situation
>> arises where virtual machines are not only managed by the cluster
>> software, but also need to participate in the cluster software
>> themselves...
>>
>> In order for this to work better, it would be good if there
>> was a way for software in a domU to communicate with software
>> on the local dom0 - so after being migrated elsewhere, a guest
>> would start talking to the new dom0 automatically.
Rik, is this a heartbeat kind of protocol or some such thing?
Is there value to making it be a generic solution that would
work when communicating in a non-xen environment?
>> Should it be some virtual device analogous to the virtual
>> network driver, or should we have some other kind of socket
>> for node local communications ?
Using protocols like TCP for node-local comms is undesirable
as TCP is engineered for the heavy machinery of the Internet.
UDP or raw sockets will be somewhat better, although AF_UNIX
would be best of all (albeit with its own constraints).
>> What kind of approach would the Xen community (that's you, if
>> you read this far) prefer ?
>>
>>
> I can only speak for myself, but I'd personally like to see a small
> userspace library that established a datagram connection between two
> domains (using an event channel and a shared page) that could be reused
> for many applications.
Which datagram service, Anthony? Having a small lib like this
would be a good idea, although the benefit would be in the details,
and of course, depending on how many apps we need to support that
we don't want to modify...
> If it could be used with normal read/write calls that would be even
> better (although first thought is that that would require a daemon).
Probably don't want to do that...
thanks,
Nivedita
next prev parent reply other threads:[~2005-06-15 21:31 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-06-15 20:08 RFC: "local" communications Rik van Riel
2005-06-15 20:24 ` Anthony Liguori
2005-06-15 21:31 ` Nivedita Singhvi [this message]
2005-06-15 21:55 ` Anthony Liguori
2005-06-15 22:07 ` Nivedita Singhvi
2005-06-16 16:15 ` Lon Hohberger
2005-06-16 2:44 ` Rusty Russell
-- strict thread matches above, loose matches on Subject: below --
2005-06-15 21:53 Ian Pratt
2005-06-15 22:10 ` Nivedita Singhvi
2005-06-15 22:43 ` Rik van Riel
2005-06-16 16:19 ` Lon Hohberger
2005-06-15 22:32 Ian Pratt
2005-06-16 2:59 ` Rusty Russell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=42B09E1E.3060709@us.ibm.com \
--to=niv@us.ibm.com \
--cc=aliguori@us.ibm.com \
--cc=lhh@redhat.com \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.