On Wed, Feb 28, 2024 at 02:56:02PM +0000, Daniel P. Berrangé wrote:
> 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.
By default, microvm is too opinionated to be considered usable as a
general-purpose machine type. For example, it uses virtio-mmio
instead of PCI, so no hotplug out of the box. It can be massaged into
something more suitable through the use of additional options, but
really at that point it would IMO make a lot more sense to introduce
a 'virt' machine type similar to the one that aarch64 and riscv64
already have, leaving microvm to its original use case.
--
Andrea Bolognani / Red Hat / Virtualization
_______________________________________________
Devel mailing list -- devel@xxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxx
