On Wed, Jun 06, 2018 at 03:36:53PM -0300, Eduardo Habkost wrote: > On Wed, Jun 06, 2018 at 08:33:39PM +0200, Michal Suchánek wrote: > [...] > > Lastly we are missing a developer of a management layer committed to > > support such appliances. > > This is important. Without developers of management tools > willing to help specify the requirements and implement the > feature, all the work in the lower layers would be useless.
FWIW, I'm following along from the OpenStack 'Nova' (it allows you to provision VMs / QEMU instances) point of view. Here is a bug (filed by Eduardo) that is tracking what needs to fixed in Nova: https://bugzilla.redhat.com/show_bug.cgi?id=1581414 -- OpenStack shouldn't break if the default machine-type in QEMU is "q35" Refer to comment#6 and comment#11 for some analysis as to where Nova makes assumptions for machine types. (There is one instance of it.) Related: Elsewhere on this KM-long thread, Dan Berrangé and myself have noted how Nova allows configuring machine types today -- either via setting a config attribute (in /etc/nova/nova.conf) per Compute node (where QEMU processes are launched) or via setting a metadata property per template disk image, which is used to launch Nova instances (VMs). -- /kashyap