Libvirt with Firecracker

[Daniel P. Berrangé]

On Thu, Sep 09, 2021 at 03:52:45PM +0000, Puscasu, Felix wrote:
> Hello Libvirt team,
> 
> For the last couple of months, as an AWS intern I have been reading
> and learning how to use libvirt. I have been working on integrating
> <Firecracker<https://github.com/firecracker-microvm/firecracker>,
> an open source virtual machine monitor into libvirt as a hypervisor
> driver, believing its design would be a great addition to the fleet
> of already existing drivers.

Yes, it is certainly in scope for libvirt if someone is willing to
work on support and maintain it.
 
> One question I have is regarding testing, I couldn’t properly use
> the libvirt-test-API repository, and neither the libvirt-TCK one.
> I am now looking at the testing done In the libvirt repository
> itself and wanted to ask if integration-like tests would be
> achievable here, and if it is in line with the project’s
> direction. We would like to have tests to be as “end to end”
> as they can.

You're basically hitting a scenario to which we don't currently
have a solution we're happy with. In terms of testing a new hypervisor
driver today, the libvirt-tck is probably the closest to being usable,
but you'll encounter stumbling blocks along the way.

It was intended to be applicable to any hypervisor river, but its
heritage involved testing mostly against Xen and QEMU both of which
provide a fairly full featured traditional virtual machine feature
set. IIUC, FireCracker provides a much more tightly defined and
opinionated feature set, discarding legacy stuff. This will almost
certainly hit some bogus assumptions in the libvirt TCK framework
and tests.

As I mentioned though it was intended to be general purpose, so it
is not out of the question to fix those edge cases by adding logic
to tailor its config to Firecracker, or to skip tests that are just
inappropriate. 


In the main libvirt.git repository the tests present are almost
exclusively unit tests, with a heavy focus on configuration file
processing. ie validating conversion between libvirt guest XML
and QEMU command line arguments, or some equivalent config for
other hypervisors.

We have a recent unresolved discussion about our future desires
for testing in libvirt, but I wouldn't suggest waiting for a
conclusion on that. We'll probably end up with something that
is conceptually similar to what libvirt-tck was trying todo,
but based around Avocado and tests written in Python, instead
of Perl. This is a bit of a long term effort though.

We are also considering how we actually run such testing, as
unless you run it regularly, everything will bitrot - both the
hypervisor code and the test suite.

> Another mention is this contribution is more of a proof of
> concept than a production ready patch/series of patches as
> it doesn’t have (yet) tests in any way. It can be a starting
> point for future contributions (that can also be from the
> open source community).

It is great that you are very interested in having it well
tested. Historically our bar for accepting new hypervisors
has been quite low with very minimal testing requirements.
So really any level of testing is welcome. The bigger question
for us is whether the submitter is willing to maintain the
contributed code in the medium-to-longer term so that it
isn't orphaned. 

> I wanted to check with you if this integration collides
> with any of your ongoing work and what would be some of
> your initial thoughts.

AFAIK, no one else has done any work on libvirt support with
relation to Firecracker.

Even if you don't think it is suitable for merging, feel
free to send patches you might have today if you want to get
some early guidance on whether the approach you're taking
fits in with normal practice for libvirt drivers.

We generally like to take code in smaller chunks, rather
than a big bang adding everything at once. Our general
minimum bar for hypervisor drivers has only required a
handful of APIs to be implemented. Something perhaps
covering the virsh comands nodeinfo, capabilities, list,
define, start, getxml, destroy. This lets you get info
about the hypervisor, and do a very basic VM create and
teardown.


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|