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

[Cole Robinson]

On 05/05/2014 07:20 AM, Laine Stump wrote:
> 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.
> 

Right, I figured :) I'm not necessarily saying you need to come up with the
final patch, I was just trying to start a discussion.

>> 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).
> 

Yes, it is inconsistent, but that's because to an end user the values of -M
have inconsistent effects as well. On arm, every -M value represents a
specific real world ARM board that is being emulated. This is very relevant to
the end user since historically a single arm kernel was compiled for a single
ARM board. In most cases, anyone creating an ARM VM _must_ know the -M type
they need/

On x86, the pc-* values are all about maintaining back compatibility with
older qemu versions, while being able to safely add features and fix bugs with
newer qemu versions. They are obviously very valuable, but to an uninformed
end user this value should _never_ be changed. So we really do want to expose
it differently for x86 vs arm.

q35 obviously adds something compared to the pc-* machine types, but I'd still
rather expose it in a different way than the machine type drop down.

> 
>>
>> 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.
> 

The same standard does not apply to libvirt as it does virt-manager. libvirt
basically wants to expose every knob, virt-manager wants to expose only those
knobs that really have value in the UI. There are some things we deliberately
choose not to expose in the UI, or that we expose in a different way than just
a plain libvirt XML mapping, to decrease likelihood of misuse.

(that said, my idea for virt-xml/virt-install _is_ to expose every knob that
libvirt exposes, so there's always a path to using one of those tools to do
something that we reject from the UI)

> 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.

In theory. In practice, we have to balance maintenance cost, potential for
misuse leading to future bug reports, and other bits. Particularly for this
feature, if hypothetically the next qemu release was going to enable q35 as
the default, I would just wait till then. Otherwise we have to do the dance:

hide_useq35_ui()
hide_usepc_ui()
if qemu_has_q35_default():
    show_usepc_ui()
elif qemu_has_pc_default() and qemu_has_q35():
    show_use_q35()

And the combinatorial testing explosion to make sure the logic is correct :)
Generally I like to avoid that type of work.

 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.
> 

Right, my expectation all along (and what was the qemu team plan at least once
upon a time) was that qemu would eventually change the default to -M q35.
Libvirt would magically pick that up via the -M ? output. q35 gets more
testing from all users across the board, and we can avoid these types of
discussions :)

> (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 :-)
> 

The current alternative is virt-install. Specifying q35 is just --machine q35.
Of course, you need to construct the rest of the command around that which
scares some people :) In the future ping me and I can help

Also, what's the main use case for q35 at the moment, something VFIO related
right? Can you elaborate?

>> 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).
> 

Right, no worries. I'll poke at it.

- Cole