Hi Gleb.
On Wed, Dec 17, 2008 at 04:31:46PM +0200, Gleb Natapov (g...@redhat.com) wrote:
Here it is. Sorry it is not in a patch format yet, but it gives
general idea how it looks. The problem with connector is that
we need different IDX for different channels and there is no way
to
On Wed, Dec 17, 2008 at 12:25:32AM +0300, Evgeniy Polyakov wrote:
On Tue, Dec 16, 2008 at 08:57:27AM +0200, Gleb Natapov (g...@redhat.com)
wrote:
Another approach is to implement that virtio backend with netlink based
userspace interface (like using connector or genetlink). This does not
On Tue, Dec 16, 2008 at 08:57:27AM +0200, Gleb Natapov (g...@redhat.com) wrote:
Another approach is to implement that virtio backend with netlink based
userspace interface (like using connector or genetlink). This does not
differ too much from what you have with special socket family, but at
Evgeniy Polyakov wrote:
On Tue, Dec 16, 2008 at 08:57:27AM +0200, Gleb Natapov (g...@redhat.com)
wrote:
Another approach is to implement that virtio backend with netlink based
userspace interface (like using connector or genetlink). This does not
differ too much from what you have with
David Miller wrote:
From: Gleb Natapov g...@redhat.com
Date: Sun, 14 Dec 2008 13:50:55 +0200
It is undesirable to use TCP/IP for this purpose since network
connectivity may not exist between host and guest and if it exists the
traffic can be not routable between host and guest for
Hi Gleb.
On Sun, Dec 14, 2008 at 01:50:55PM +0200, Gleb Natapov (g...@redhat.com) wrote:
There is a need for communication channel between host and various
agents that are running inside a VM guest. The channel will be used
for statistic gathering, logging, cut paste, host screen resolution
Anthony Liguori wrote:
David Miller wrote:
From: Gleb Natapov g...@redhat.com
Date: Sun, 14 Dec 2008 13:50:55 +0200
It is undesirable to use TCP/IP for this purpose since network
connectivity may not exist between host and guest and if it exists the
traffic can be not routable
-Original Message-
From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On
Behalf Of Jeremy Fitzhardinge
The trouble is that it presumes that the host and guest (or whoever the
endpoints are) are on the same physical machine and will remain that
way. Given that live
From: Anthony Liguori anth...@codemonkey.ws
Date: Mon, 15 Dec 2008 09:02:23 -0600
There is already an AF_IUCV for s390.
This is a scarecrow and irrelevant to this discussion.
And this is exactly why I asked that any arguments in this thread
avoid talking about virtualization technology and why
David Miller wrote:
From: Anthony Liguori anth...@codemonkey.ws
Date: Mon, 15 Dec 2008 09:02:23 -0600
There is already an AF_IUCV for s390.
This is a scarecrow and irrelevant to this discussion.
And this is exactly why I asked that any arguments in this thread
avoid talking
From: Anthony Liguori anth...@codemonkey.ws
Date: Mon, 15 Dec 2008 14:44:26 -0600
We want this communication mechanism to be simple and reliable as we
want to implement the backends drivers in the host userspace with
minimum mess.
One implication of your statement here is that TCP is
Anthony Liguori wrote:
Jeremy Fitzhardinge wrote:
Each of these sockets are going to be connected to a backend (to
implement guest=copy/paste for instance). We want to implement
those backends in userspace and preferably in QEMU.
Using some raw protocol over ethernet means you don't
David Miller wrote:
From: Anthony Liguori anth...@codemonkey.ws
Date: Mon, 15 Dec 2008 14:44:26 -0600
We want this communication mechanism to be simple and reliable as we
want to implement the backends drivers in the host userspace with
minimum mess.
One implication of your
Jeremy Fitzhardinge wrote:
Anthony Liguori wrote:
That seems unnecessarily complex.
Well, the simplest thing is to let the host TCP stack do TCP. Could
you go into more detail about why you'd want to avoid that?
The KVM model is that a guest is a process. Any IO operations original
On Mon, 15 Dec 2008 17:01:14 -0600
Anthony Liguori anth...@codemonkey.ws wrote:
David Miller wrote:
From: Anthony Liguori anth...@codemonkey.ws
Date: Mon, 15 Dec 2008 14:44:26 -0600
We want this communication mechanism to be simple and reliable as we
want to implement the backends
David Miller wrote:
From: Anthony Liguori anth...@codemonkey.ws
Date: Mon, 15 Dec 2008 17:01:14 -0600
No, TCP falls under the not simple category because it requires the
backend to have access to a TCP/IP stack.
I'm at a loss for words if you need TCP in the hypervisor, if that's
Anthony Liguori wrote:
Jeremy Fitzhardinge wrote:
Anthony Liguori wrote:
That seems unnecessarily complex.
Well, the simplest thing is to let the host TCP stack do TCP. Could
you go into more detail about why you'd want to avoid that?
The KVM model is that a guest is a process. Any
Evgeniy Polyakov wrote:
On Mon, Dec 15, 2008 at 05:08:29PM -0600, Anthony Liguori
(anth...@codemonkey.ws) wrote:
The KVM model is that a guest is a process. Any IO operations original
from the process (QEMU). The advantage to this is that you get very
good security because you can
Hi Evgeniy,
On Sun, Dec 14, 2008 at 03:23:20PM +0300, Evgeniy Polyakov wrote:
On Sun, Dec 14, 2008 at 01:50:55PM +0200, Gleb Natapov (g...@redhat.com)
wrote:
There is a need for communication channel between host and various
agents that are running inside a VM guest. The channel will be
There is a need for communication channel between host and various
agents that are running inside a VM guest. The channel will be used
for statistic gathering, logging, cut paste, host screen resolution
changes notifications, guest configuration etc.
It is undesirable to use TCP/IP for this
From: Gleb Natapov g...@redhat.com
Date: Sun, 14 Dec 2008 13:50:55 +0200
It is undesirable to use TCP/IP for this purpose since network
connectivity may not exist between host and guest and if it exists the
traffic can be not routable between host and guest for security reasons
or TCP/IP
21 matches
Mail list logo
