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