Re: Improve default machine type selection

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Apr 05, 2023 at 15:19:07 -0600, Jim Fehlig wrote:
> On 3/16/23 11:56, Jim Fehlig wrote:
> > On 3/15/23 08:40, Ján Tomko wrote:
> > > On a Monday in 2023, Jim Fehlig wrote:
> > > > If an explicit machine type is not specified in the VM config,
> > > > the qemu driver will select the first machine type in the list
> > > > of machine types for the specified accelerator. See
> > > > virQEMUCapsGetPreferredMachine
> > > > 
> > > > https://gitlab.com/libvirt/libvirt/-/blob/master/src/qemu/qemu_capabilities.c#L6133
> > > > 
> > > > On my test machines, this works reasonably well for x86_64 where
> > > > the first machine type is pc-i440fx-7.1. But for aarch64, the
> > > > first machine is integratorcp, which is not very useful with
> > > > maxCpus=1 and other limitations.
> > > 
> > > Is it possible to run such machine with libvirt?
> > 
> > I just did a quick check with libvirt 9.1.0 (qemu is a bit older, at 7.1.0):
> > 
> > # cat test.xml
> > <domain type='kvm'>
> >    <name>test</name>
> >    <memory unit='KiB'>2097152</memory>
> >    <vcpu placement='static'>1</vcpu>
> >    <os>
> >      <type>hvm</type>
> >      <loader readonly='yes'
> > type='pflash'>/usr/share/qemu/aavmf-aarch64-code.bin</loader>
> >      <nvram template='/usr/share/qemu/aavmf-aarch64-vars.bin'/>
> >      <boot dev='hd'/>
> >    </os>
> >    <clock offset='utc'/>
> >    <on_poweroff>destroy</on_poweroff>
> >    <on_reboot>restart</on_reboot>
> >    <on_crash>destroy</on_crash>
> >    <devices>
> >      <emulator>/usr/bin/qemu-system-aarch64</emulator>
> >      <disk type='file' device='disk'>
> >        <driver name='qemu' type='qcow2' discard='unmap'/>
> >        <source file='/var/lib/libvirt/images/test.qcow2'/>
> >        <target dev='vda' bus='virtio'/>
> >      </disk>
> >    </devices>
> > </domain>
> > # virsh create test.xml
> > error: Failed to create domain from test.xml
> > error: internal error: Unexpected enum value 0 for virDomainDeviceAddressType
> > 
> > I don't _think_ it's a downstream bug, nor fixed in git in the meantime.
> > It appears running the old integratorcp machine with libivrt is not
> > possible.
> 
> I trimmed the config to remove things like virtio devices that are not
> supported by the default machine type, but still it does not work with
> libvirt:
> 
> # cat test.xml
> <domain type='kvm'>
>   <name>test</name>
>   <memory unit='KiB'>2097152</memory>
>   <vcpu placement='static'>1</vcpu>
>   <os>
>     <type>hvm</type>
>   </os>
>   <devices>
>     <emulator>/usr/bin/qemu-system-aarch64</emulator>
>   </devices>
> </domain>
> # virsh create test.xml
> error: Failed to create domain from test.xml
> error: internal error: process exited while connecting to monitor:
> 2023-04-05T20:36:19.564896Z qemu-system-aarch64: Property
> 'integratorcp-machine.acpi' not found

This is a known issue which should be already fixed if you use the
upcoming qemu version.

Historically ACPI was controled via '-no-acpi' which is issued when you
don't use the '<acpi/>' feature element in the definition. Also
historically it was only used on x86. With development of the 'virt'
machine type for arm which does use acpi this was un-carefully extended
to aarch64 as well where it didn't work with non-virt machines.

Now with the latest qemu which reports which machine type actually
support ACPI we avoid use of '-no-acpi' for those which don't support
it.

Unfortunately the workaround of adding <acpi/> element to definition for
a machine which doesn't have it doesn't work either, because a further
validation check forces you to configure uefi if you want acpi.




[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]

  Powered by Linux