On Tue, Nov 10, 2015 at 01:17:41PM +0100, Christian Loehle wrote:
>From README:
The jailhouse hypervisor driver for the libvirt project aims to provide
rudimentary support for managing jailhouse with the libvirt library. The
main advantage of this is the possibility to use virt-manager as a GUI
to manage Jailhouse cells. Thus the driver is mainly built around the
API calls that virt-manager uses and needs.
Due to the concept of Jailhouse a lot of libvirt functions can't be
realized, so this driver isn't as full-featured as upstream drivers of
the libvirt project.
Currently the driver relies on the Jailhouse binary, which has to be
passed when connecting a libvirt client to it(e.g. virt-manager -c
jailhouse:///path/to/jailhouse/tools/jailhouse). This has the advantage
that remote support can be easily done by not passing the original
Jailhouse binary, but an executable that redirects its parameters
through ssh to the real Jailhouse binary and outputs that output. Be
I'm not a huge fan of that idea to be honest. Normal practice is for
libvirt to look in $PATH to locate hypervisor binaries it needs. It
then reports this binary in the capabilities XML as the emulator
binary. The user can override this binary when creating a guest by
passing a custom <emulator> element in the guest XML. So I don't
really see a compelling reason to require the binary to be passed
in the URI. As for remote support, libvirt has long had remote RPC
access that works with all hypervisor drivers.
Regards,
Daniel
--
|:
http://berrange.com -o-
http://www.flickr.com/photos/dberrange/ :|
|:
http://libvirt.org -o-
http://virt-manager.org :|
|:
http://autobuild.org -o-
http://search.cpan.org/~danberr/ :|
|:
http://entangle-photo.org -o-
http://live.gnome.org/gtk-vnc :|