On 12/10/19 5:57 AM, Daniel P. Berrangé wrote:
>
>> Another issue: other drivers use the machine= setting too, libxl at
>> least. This appears to drop filling in a default machine type for them,
>> at least at XML parse time.
>
> I thought that was the case too, but I couln't find any functional use
> of def->os.machine in any of the other drivers:
>
> $ git grep os.machine | grep -v -E '(qemu|conf)/'
> libvirt-domain.c: * "os.machine" - the machine hardware name as a string
> libxl/libxl_conf.c: def->os.machine);
> libxl/xen_common.c: def->os.machine = g_strdup(capsdata->machinetype);
> vbox/vbox_common.c: VIR_DEBUG("def->os.machine %s", def->os.machine);
> vz/vz_sdk.c: if (def->os.machine != NULL || def->os.bootmenu != 0 ||
>
>
> that libxl_conf.c usage is just an error message
>
> The xen_common.c usage is just when parsing XM/XL config files,
> so output only.
>
> The vz_sdk.c usage reports error for any non-NULL machine
>
>
> I guess there is a difference in that if the user does dumpxml for a
> libxl guest we've no longer filled in the machine. I can fix that,
> but it doesn't look like it'll have a functional effect.
Check grep for 'xenfv' and 'xenpv', domaincapabilities does some machine
value handling, and virt-manager will use the reported VM machine value
and feed it back to domaincapabilities, so it could be used in a round
about way.
Thanks,
Cole
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
