QIP Proposal - Vios QPID Message Transport over KVM Virtioserial channels

[Chuck Rolke <cr...@redhat.com>]

# Title

Vios - QPID Message Transport over KVM Virtioserial channels

# Status

Draft

# Summary

A new transport protocol using KVM virtioserial ports to provide
secure, high-performance channels between a broker in a KVM Host and
clients in KVM Guests.

# Problem

At present the only way for a KVM-guest QPID client to connect to a
KVM-host QPID broker is to use a KVM network interface between the
guest and host.  For security reasons some guest processes are
configured with no network interfaces and thus rule out this
connection method. Other customers do not want the host QPID broker to
expose itself over a network interface.

See also: http://www.linux-kvm.org/page/VMchannel_Requirements

# Solution

A new transport mechanism (Vios) is developed to provide negotiated
access to a host broker from the guest clients over virtioserial
ports. The proposed design has the following:

* Virtioserial channels are created synchronously with the creation of
the guest VM.  

* The host broker is configured to manage groups of virtioserial
channels where each group represents the channels to a single guest
VM.

* The guest clients attach to one of the channels created for its
guest VM.

* The host broker and guest client negotiate using the Vios
protocol. Upon successful negotiation the client and broker open a
QPID connection.

* The Vios transport is delivered as a plug-in similar to RDMA
allowing its use to be controlled or excluded by command line options.

* Vios channel security is provided by host domain socket permissions
and by guest file handle permissions.

# Rationale

The obvious solution of connecting a KVM host broker to a KVM guest
client is a KVN network. However, this solution is ruled out for
various administrative reasons.

The KVM virtioserial channel was developed specifically as a
chardev-based tunnel between KVM host and guest processes. With only a
moderate effort the KVM virtioserial channels may be used as a QPID
message transport.

On the host (broker) a virtioserial connection appears as a domain
socket. The proposed Vios solution is not a generic addition of domain
sockets to the current network sockets. In the Vios scheme the broker
must actively open connections to the domain sockets and not connect
by the usual listen-accept methods.

# Implementation Notes

The Vios transport will be added in parallel to RDMA: new directory
cpp/src/qpid/sys/vios is added and the bulk of the code is there. The
broker will use cpp/src/qpid/sys/ViosIOPlugin.cpp and the client will
use cpp/src/qpid/client/ViosConnector.cpp.

No other components in QPID are affected.

# Consequences

Development:

This should not affect how developers work on Qpid. The
changes/additions are localized and do not require the installation of
any external libraries.

Release:

This will not affect the release process.

Documentation:

Additions to the documentation are required for both the broker and
client use cases. Examples are needed to illustrate the life cycles
of the broker connections and guest VMs.

Configuration:

Initial configuration is provided on the broker and client command
lines, and in the broker and client process environment.

The broker may be required to respond to dynamic changes to the list
of supported guest VMs after the broker has started.

Compatibility:

It does not break API for the broker or the client. It extends the
schema supported in both the broker and the client.

# Contributor-in-Charge

crolke@redhat.com

# Contributors

TBD

# Version

1.0

---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org