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 :|
_______________________________________________
Devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]
