On Wed, Feb 28, 2024 at 06:35:46AM -0800, Andrea Bolognani wrote:
On Tue, Feb 27, 2024 at 05:36:08PM +0100, Peter Krempa wrote:
> @@ -4157,6 +4158,14 @@ qemuDomainDefAddDefaultDevices(virQEMUDriver *driver,
> switch (def->os.arch) {
> case VIR_ARCH_I686:
> case VIR_ARCH_X86_64:
> + /* don't add anything for microvm */
> + if (qemuDomainIsMicrovm(def)) {
> + /* explicitly add 'none' USB controller */
> + usbModel = VIR_DOMAIN_CONTROLLER_MODEL_USB_NONE;
> + addDefaultUSB = true;
> + break;
> + }
I'm not terribly keen on seeing support for microvm officially
introduced in libvirt.
AFAIK nobody ever asked for it, and given that the intended use case
for the machine type is specifically to have incredibly minimal, fast
booting VMs, to the extent where trimmed out kernels and even custom
firmware implementations are employed to shave every last possible
microsecond off the boot time, I really don't expect that anyone
would ever consider using libvirt to manage them.
What you describe is one use case for microvm, but more generally
I'd say microvm provides a "legacy free" machine type. Q35 is still
a legacy platform, just a little less legacy than i440fx.
By eliminating legacy platform features, microvm reduces the guest
machine attack surface. As such, I think it is conceptially relevant
to want to use microvm for general purpose guest OS, while not caring
about its supposed performance differences.
With 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 :|