A libvirt client can connect to libvirt on a remote host. However, on
its own this doesn't give the client a usable level of access. The
reason for this is that libvirt doesn't expose some critical management
interfaces. For QEMU this amounts to pretty much anything provided
directly by the QEMU process, including:
* VNC console [1]
* Any character device [2]
I'm undecided as to whether access to underlying storage falls into this
bucket. It would certainly be convenient in certain circumstances.
This means, for example that I need out of band access to:
* See a graphical console
* Connect to a serial console
* Connect to a guest channel
As these are fairly fundamental operations, I wonder if there has been
any thought towards creating tunnels over a libvirt connection.
In the first instance, I think this would require a generic method to
multiplex multiple streams over a single remote connection. This would
obviously be a significant protocol change. Would a messaging protocol,
AMQP for instance, be a good candidate here?
Secondly, I think interfaces which currently create local resources
should have a default which is managed by libvirt itself. So you'd have:
<serial>
<target port='0'/>
</serial>
or
<serial type='managed'>
<target port='0'/>
</serial>
This would cause libvirt to create whichever host-side chardev is most
convenient to it and connect itself. The API would then expose read and
write APIs for the named connection. e.g:
virDomainFoo foo;[3]
if = virDomainGetFoo(domain, "serial0");
bytesIn = virDomainFooRead(foo, &buf, sizeof(buf));
A client application could expose this in a variety of ways locally.
Matt
[1] There's an open RFE for this one:
https://bugzilla.redhat.com/show_bug.cgi?id=526953
[2] e.g.
virsh # console RHEL3.FV.64.IDE
error: Cannot connect to a remote console device
[3] What would you call it?
--
Matthew Booth, RHCA, RHCSS
Red Hat Engineering, Virtualisation Team
M: +44 (0)7977 267231
GPG ID: D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490
--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list