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 :|
