[virt-tools-list] [virt-manager PATCH] support creation of x86_64 domains with alternate machine types (e.g. q35)

Mon May 5 11:20:20 UTC 2014

On 05/03/2014 08:40 PM, Cole Robinson wrote:
> On 05/02/2014 10:16 AM, Laine Stump wrote:
>> In an apparent attempt to simplify creation of x86_64 domains,
>> create.py has always cleared out the list of possible machine types,
>> thus forcing all new domains to use the default machine type "pc". Now
>> that the much more modern machinetypes based on the Intel Q35 chipset
>> are available in qemu, it is more important to allow the user to
>> select the machine type when creating a machine.
>>
>> This patch makes the default machine type "pc", but adds "q35" as a
>> secondary "priority" selection (meaning that it will be placed at the
>> top of the list). I also noticed that all the more specific
>> machinetypes supported by qemu were duplicated (possibly due to
>> combining the list for x86_64 and i686?), so I made a modification to
>> remove duplicates in the list.
>>
>> Since virt-manager now defaults to adding USB 2.0 controllers to new
>> machines, this small change allows virt-manager to create fully
>> functioning Q35 machines.
> Thanks for the patch. However the UI isn't acceptable as-is IMO.
>
> The reason we hide the machine types is because they are plain confusing:
> pc-1.3, pc-1.4, or even worse rhel-6.3, rhel-6.4, etc. 99% of users won't know
> what any of the options mean.

Yeah, I agree with that. This being the first time I looked at
virt-manager's source in detail, I saw a simple way to make it behave
more consistently between different archs, while using existing
infrastructure to get what I wanted, which was simply a way to select
q35 easily.

> So IMO the way to expose q35 is with a checkbox like 'Use Q35 chipset'.

Looking from the point of view of what is exposed from qemu, that is a
bit inconsistent with the presentation of ARM machine types in
virt-manager, although I guess the machine type is used in a slightly
different way in the ARM qemu (there seem to be much more fundamental
differences between the various types, although maybe that is again just
my warped view as an outsider to ARM).

>
> But is q35 even 'ready' yet? Does it still block migration? Is there any
> roadmap to make it the default?
This all depends on your definition of "ready" :-) I haven't done any
stress testing, and I do know about the inability to migrate the SATA
controller, but it certainly works well enough to start up a q35-based
guest that remains on one host. And there will be more testing/bug
squashing if it is possible to select it from within virt-manager - if
we followed the above logic to its conclusion, then libvirt would still
not support setting q35 because the sata controller can't be migrated,
and we would be stuck in indefinite limbo.

As for making it the default - since any given virt-manager has to be
able to operate properly with any vintage of libvirt+qemu, I don't think
that should have anything to do with whether the option to manually
select Q35 is available in virt-manager - if qemu and libvirt have that
option, then virt-manager should allow selecting it. Making it the
default is something that would have to come from qemu/libvirt in the
form of capabilities; perhaps libvirt will (based on what it's told by
qemu), return this in the capabilities:

      <machine canonical='pc-q35-1.6' maxCpus='255'>pc</machine>

instead of this:

      <machine canonical='pc-i440fx-1.6' maxCpus='255'>pc</machine>

That's just an off-the-cuff speculation though; I haven't really thought
about the implications.

(I actually looked into the virt-manager code and made this patch after
a 2nd person asked on IRC how to create a q35 machine with virt-manager.
Without direct support, it's not as simple as just creating a standard
guest and then editing it to change "pc-whatever" to "q35" - you also
have to remove all device PCI addresses, and all PCI controllers so that
libvirt can re-create/re-assign it all based on the new machine type.
Normally I would have just whined about the lack of support in
virt-manger and left it at that, but the patch turned out to be so
simple that I had to share it :-)

> Even if it is in good shape these days, I'd rather hide this option on the VM
> details window, so knowledgable users have to go find it behind 'customize
> before install'.

I think the "Architecture" drop-down is a hidden enough place, and
consistent with what is done with ARM. I do agree that having the list
of all the versioned arches is overkill, though (and don't see nearly as
much utility for them as a simple "440fx vs. Q35" selection like you
suggest) - that was just a "freebie" that came along with my minimalist
patch attempt.

But then I'm just a casual virt-manager user, and spent no more than an
hour thinking about this, while I'm sure you've considered it quite a
lot more, so if you have different plans then that's okay with me :-) If
it's going to be anything that requires actually adding new
functionality (rather than just tweaking what's already there), then I
think I should leave it to you or someone else more directly involved
with virt-manager though. (I do think that we shouldn't be waiting until
Q35 is 100% bugfree to support it in virt-manager though - not only will
it give the q35 code more exposure, but it will eliminate the need for
lots of hand holding in IRC as more and more people decide to try out Q35).

>> Thanks,
>> Cole
>>
>> ---
>>  virtManager/create.py | 14 ++++++++------
>>  1 file changed, 8 insertions(+), 6 deletions(-)
>>
>> diff --git a/virtManager/create.py b/virtManager/create.py
>> index c2e0ee7..4fd8a8a 100644
>> --- a/virtManager/create.py
>> +++ b/virtManager/create.py
>> @@ -710,19 +710,21 @@ class vmmCreate(vmmGObjectUI):
>>          model.clear()
>>  
>>          machines = self.capsdomain.machines[:]
>> -        if self.capsguest.arch in ["i686", "x86_64"]:
>> -            machines = []
>> -        machines.sort()
>> -
>> -        defmachine = None
>>          prios = []
>> -        if self.capsguest.arch == "armv7l":
>> +        defmachine = None
>> +
>> +        if self.capsguest.arch in ["i686", "x86_64"]:
>> +            defmachine = "pc"
>> +            prios = [ "pc", "q35" ]
>> +        elif self.capsguest.arch == "armv7l":
>>              defmachine = "vexpress-a9"
>>              prios = ["vexpress-a9", "vexpress-a15", "highbank", "midway"]
>>          elif self.capsguest.arch == "ppc64":
>>              defmachine = "pseries"
>>              prios = ["pseries"]
>>  
>> +        machines = sorted(set(machines))
>> +
>>          for p in prios[:]:
>>              if p not in machines:
>>                  prios.remove(p)
>>
> _______________________________________________
> virt-tools-list mailing list
> virt-tools-list at redhat.com
> https://www.redhat.com/mailman/listinfo/virt-tools-list
>