On Thu, Sep 09, 2021 at 03:52:45PM +0000, Puscasu, Felix wrote: Yes, it is certainly in scope for libvirt if someone is willing to work on support and maintain it. 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. 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. 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 :|