Improving libvirt support for bhyve
Fabian Freyer
fabian.freyer at physik.tu-berlin.de
Sat Jun 25 18:01:10 UTC 2016
Hi everybody,
unfortunately I had overlooked the fact that I should have provided weekly
status reports to this list, so in this mail I will present what I've done so
far and will aim to update this thread regularly from now on. Therefore this
initial mail will be a bit lengthy.
Introduction
============
The primary aim of this project is to implement missing calls and functionality
in the libvirt bhyve driver. A number of API calls are not yet implemented, and
are still to be implemented. Details can be found on my wiki page [1]. Since
this is mostly code that is contributed to the libvirt project, I base my
patches off the libvirt git repository [2] and host a development fork on Github
[3].
Things I have achieved so far
=============================
Simple calls
------------
I have implemented some simple calls for the bhyve driver and already upstreamed
them:
* https://libvirt.org/git/?p=libvirt.git;a=commitdiff;h=126e630e85311a57f87709a269bc55059cb3cf44
* https://libvirt.org/git/?p=libvirt.git;a=commitdiff;h=a1efc9428bcdf6075fac0dac4d73ff2858216d7f
* https://libvirt.org/git/?p=libvirt.git;a=commitdiff;h=32aa9ed3ba2117936b8634091330418573d9b8c8
* https://libvirt.org/git/?p=libvirt.git;a=commitdiff;h=ef45eb9bc7782a1edb7237bb0307afe576d287d4
bhyveConnectDomainXMLFromNative
-------------------------------
For the last weeks, the majority of my work was focused on implementing a call
that generates a libvirt domain definition XML file from a native bhyve and
bhyveload command string. The first three versions of this patch series have
already hit the libvirt mailing list [4], and I aim to submit v4 to the libvirt
mailing list early next week.
For a detailed overview of the work I have done there, I will cite or summarize
the commit messages of the last submitted patch series:
* I found a bug (?) in gnulib on FreeBSD where several gnulib headers rely on
features.h being included by ctype.h to provide __GNUC_PREREQ, but on systems
without glibc (such as FreeBSD), this is not provided. This is yet to be
reported to gnulib, but I've created a workaround for libvirt so far.
* I've imported the getopt-posix gnulib module into the libvirt build
* I've created some string-handling functions that unescape the original command
line and splits it up into an argv-list for the bhyve loader and bhyverun
commands, respectively.
* A simple getopt-based argument parser is added for the /usr/sbin/bhyve
command, loosely based on its argument parser, which reads the following from
the bhyve command line string:
* vm name
* number of vcpus
* memory size
* the time offset (UTC or localtime). This includes a capability check to see
if this is actually supported by the bhyve version.
* features:
* acpi
* ioapic: While this flag is deprecated in FreeBSD r257423, keep checking
for it for backwards compatibiility.
* the domain UUID; if not explicitely given, one will be generated.
* lpc devices: for now only the com1 and com2 are supported. It is required
for these to be /dev/nmdm[\d+][AB], and the slave devices are automatically
inferred from these to be the corresponding end of the virtual null-modem
cable: /dev/nmdm<N>A <-> /dev/nmdm<N>B
* PCI devices:
* Disks: these are numbered in the order they are found, for virtio and ahci
disks separately. The destination is set to sdX or vdX with X='a'+index;
therefore only 'z'-'a' disks are supported.
Disks are considered to be block devices if the path
starts with /dev, otherwise they are considered to be files.
* Networks: only tap devices are supported. Since it isn't possible to tell
the type of the network, VIR_DOMAIN_NET_TYPE_ETHERNET is assumed, since it
is the most generic. If no mac is specified, one will be generated.
* A simple getopt-based argument parser is added for the /usr/sbin/bhyveload
command, loosely based on its argument parser.
The boot disk is guessed by iterating over all
disks and matching their sources. If any non-default arguments are found,
def->os.bootloaderArgs is set accordingly, and the bootloader is treated as a
custom bootloader.
Custom bootloader are supported by setting the def->os.bootloader and
def->os.bootloaderArgs accordingly
grub-bhyve is also treated as a custom bootloader. Since we don't get the
device map in the native format anyways, we can't reconstruct the complete
boot order. While it is possible to check what type the grub boot disk is by
checking if the --root argument is "cd" or "hd0,msdos1", and then just use the
first disk found, implementing the grub-bhyve argument parser as-is in the
grub-bhyve source would mean adding a dependency to argp or duplicating lots
of the code of argp. Therefore it's not really worth implementing that now.
In the last week I have been working on incorporating the feedback I got on my
previous patches as well as creating a number of unit tests for the patch
series. Currently I only have positive-tests (check that things work) for most
of the options of the bhyverun command, but none yet for the loader command. I
also aim to implement some negative tests to check that things that should fail
or report a warning do so; and then re-submit my patches to the libvirt-mailing
list.
My latest work on this feature can be found in the
gsoc/rebase/bhyveConnectDomainXMLFromNative_v4 branch on Github.
Bhyve UEFI Support
------------------
As a secondary focus (mostly to get a bit of distance to the code for the Native
to XML feature to get a different perspective on it) I have been playing around
with the bhyve uefi boot support, and discussing how best to change the libvirt
driver for bhyve to support booting using UEFI firmwares.
I've introduced a capability check whether bhyve supports -l bootrom (it is
seemingly not very easy to check what a given bhyve binary supports or even
what version it is apart from checking uname; I think this is one of the reasons
why my mentor novel@ created a patch [5] to see what PCI and LPC devices are
supported - if this would get into 11 it would be a huge help), and discussed
how the bootrom best be specified in the domain definiton, namely by specifying
the firmware blob in a <loader type="pflash"> tag within the <os> tag.
However, when booting using an UEFI bootrom, no loader command should be
specified; this means a number of things in the logic that builds a bhyve
command string from a libvirt domain definition need to be changed. I am
currently still trying to see how best to do this in a way that keeps everything
else working.
However, I have deliberately designed the Native->XML code in a way that adding
this feature would be simple, and plan to integrate that should that patch
serios get accepted.
Takeaways and Conclusions
=========================
From the work I've done so far I have developed a better understanding of the
libvirt code base and the time and effort it takes to implement features in a
libvirt driver. This enables me to more realistically plan my second half of the
coding period, during which I plan to finish my work on the Native->XML feature
as well as UEFI boot support. While I will further incorporate feedback on the
Native->XML feature, it will no longer be a key focus of my work (since most of
it will be done - hopefully) and instead I will shift to working on getting
reboot and reset working.
Further details on my plan will be published on the wiki page [1] as they become
clear.
Fabian
Links:
[1] https://wiki.freebsd.org/SummerOfCode2016/ImprovingLibvirtSupportForBhyve
[2] https://libvirt.org/git/?p=libvirt.git;a=summary
[3] https://github.com/fabianfreyer/libvirt
[4] https://www.redhat.com/archives/libvir-list/2016-June/msg00001.html
https://www.redhat.com/archives/libvir-list/2016-June/msg00728.html
https://www.redhat.com/archives/libvir-list/2016-June/msg01741.html
[5] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210111
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/soc-status/attachments/20160625/cf004c29/attachment.sig>
More information about the soc-status
mailing list