Anthony Liguori wrote:
> David Miller wrote:
>
>> From: Gleb Natapov <gleb@xxxxxxxxxx>
>> 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 traffic can be firewalled (by mistake) by unsuspecting VM user.
>>>
>>>
>> I don't really accept this argument, sorry.
>>
Yes. There's no reason why the management stack couldn't implement its
own private idiot-proofing network for this kind of thing.
> 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 have reliability.
> If you use a protocol to get reliability (like TCP), you now have to
> implement a full TCP/IP stack in userspace or get the host kernel
> involved. I'd rather not get the host kernel involved from a security
> perspective.
>
There's nothing wrong with user-mode TCP, or you could run your TCP
stack in a special-purpose guest if you're really paranoid.
> An inherently reliable socket transport solves the above problem while
> keeping things simple. Note, this is not a new concept. There is
> already an AF_IUCV for s390. VMware is also developing an AF_VMCI
> socket family.
>
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 migration is a feature that people seem to like,
then you'd end up needing to transport this protocol over a real network
anyway - and at that point you may as well use proper TCP/IP. The
alternative is to say either "if you use this feature you can't migrate,
and you can only resume on the same host", or "you can use this feature,
and we'll work out a global namespace and proxy it over TCP for you".
Neither seems very satisfactory.
J
_______________________________________________
Virtualization mailing list
Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/virtualization
