12:19 p.m.
On 07/02/2014 12:07 PM, Michal Privoznik wrote:
On 02.07.2014 16:32, John Ferlan wrote:
>
>
> On 06/30/2014 11:31 AM, Michal Privoznik wrote:
>> This new module holds and formats capabilities for emulator. If you
>> are about to create a new domain, you may want to know what is the
>> host or hypervisor capable of. To make sure we don't regress on the
>> XML, the formatting is not something left for each driver to
>> implement, rather there's general format function.
>>
>> The domain capabilities is a lockable object (even though the locking
>> is not necessary yet) which uses reference counter.
>>
>
> I started looking at these yesterday, but ended up having more questions
> than I originally thought I would, so perhaps better to get some
> answered. Of course it's already too wordy (sorry)...
>
> I was trying to envision use cases - that is how is this expected to be
> used and what "knowledge" is assumed of the caller/user vs. being
> designed to a more naive user trying to glean information about what's
> available. You have a very specific use case described - can I determine
> if vfio is supported, but that requires someone knowing quite a bit of
> information that isn't easily accessible unless you read sources or have
> a bit of history built up.
Well, that's only for start. Rich already requested some extensions
which will be a follow up patches.
I saw those in the original RFC posting and I see Dan updated the bz to
point at the RFC that resulted in this series...
>
> For the domcapabilities command that eventually gets added - how does
> one know what to provide for the 4 options without knowing a bit about
> the environment. It seems the assumption is the user knows to pass
> certain elements.
>
> The 'virttype' is pretty easy - that comes from the connection - so I
> wonder why it's a parameter to be provided. Does one really have to have
> a connection to get the data?
Consider 'kvm' vs 'qemu'. Or more verbose:
<domain type='kvm'/> vs <domain type='qemu'/>
Both of these are served by qemu:///{system,session} but cannot be
guessed from the connection URI.
oh yeah - right... And if I supply "kvm" or "qemu", both will use
the
qemu_driver.c code to resolve defaults for emulatorbin, arch, and
machine right? To that degree they're synonyms. It's only when filling
in the details of the domaincaps from qemucaps does it matter.
>
> The 'emulatorbin' is less obvious. If it's not passed, there is a way to
> get the default value given that you have a virttype, an os type, and an
> os arch using virCapabilitiesDefaultGuestEmulator(). What if someone
> provides "/usr/bin/qemu-kvm" or "/usr/libexec/qemu-kvm" or is
there an
> expectation of /usr/bin/qemu-system-x86_64?
Yes, there are several possibilities. Either you'll pass emulatorbin
(which corresponds to <emulator/> in domain XML) or it's defualt value
is guessed from the rest of the arguments. But this is how it works in
qemu. In other drivers it may work differently (once implemented).
Right - understood it's in the domain, but if you don't have a domain,
you still may not know what to provide. The qemu driver code expects
you to pass either "arch" or "emulator" in order to provide anything.
So you have to know one or the other to get something and the only place
to get that would then be the virsh capabilities output which I figured
out after I'd written most of the original response.
>
> The 'arch' requires a bit more knowledge, but is certainly
"obtainable"
> as a default by the current host arch, right? There's also
> virCapabilitiesDefaultGuestArch(). However, if someone was looking to
> find out what was running on the remote connection (not the local
> machine), then that assumption would be incorrect. Seems we should be
> able to figure out what arch is associated with the connection.
I don't think so. You can run ARM guest on x86_64 machine (where the
connection is to the x86_64 machine and you are querying capabilities
for ARM emulation).
So again - you have to know emulator or arch for qemu and that is
fetched from virsh capabilities - something that could be at least
documented. That is - how to figure what to pass to virsh
domcapabilities... (something that gets more difficult to type every
time I type it :-) - "domcaps" is so much easier...)
>
> I think 'machine' is perhaps the most odd to provide; however, like arch
> and emulatorbin, there is virCapabilitiesDefaultGuestMachine() to help
> you out. For this if one passed "pc" does that work - or do they have
> to pass something like "pc-i440fx-1.6" with the next question being how
> would they know to generate that?
Again, this is something that users may provide, or they can let libvirt
to fill in the sane default. Consider if you want to run, e.g. 'isapc'
(yeah, why would anybody do that? But that's a different story :P).
Right and it's not clear what has to be provided until one runs the
command for the 'virttype'...
>
> Reading the domain_conf code - only 'virttype' and 'os_type' really
seem
> to be required - everything else can be figured out "by default" given
> the two.
Correct. That's why the client side of the API checks only for the valid
connection and the rest of the checks is left for drivers to implement,
since (in general) different drivers have different sets of minimal
arguments required.
The piece of the puzzle that's missing from the descriptions -
user/customer has to start somewhere though.
Having (a) virsh command(s) to display possible options may be
> a nice addition, especially for the naive user... Should be very easy to
> add something that could print out the virArch options. Leaving only the
> need to know what the os_type is before behing able to at least fetch
> defaults and generate XML output. Perhaps someone just using "virsh
> domcapabilities" would print out tables of all arch's.. Similarly if
> arch was provided, then print out all emulatorbin's (if that's possible)
> for the arch or just the default emulatorbin... Given an arch and
> emulatorbin, then print out the machines available.
Sure, virsh user friendliness is not something I'm so proud of. But I
have nothing else to say that "patches are welcome". I mean, there are
other commands that take string values that only XML struct aware user
knows about: attach-disk is rich of examples (--driver, --cache, ...)
Right/Understood - there are certainly other examples where figuring out
the right incantation to use can be a challenge. This change is like a
gift that keeps giving in order to hopefully one day catch up to
everything that's currently supported and then "require it" (by some
rule) for anything added.
The series does scratch an itch to solve a specific problem - knowing
whether vfio is supported or not for a specific virttype, arch, machine,
and emulator, but it also opens Pandora's box of never ending requests
to display some specific feature someone is interested in.
Yes, like you note - patches are welcome... Still need to understand
the vision so that patches are useful... For instance if a "--list"
option was added to essentially print everything that we knew about
based on what was in virsh capabilities...
I'm not opposed to the patches and you have Dan's ACK - my only hope is
a clearer understanding of what's there now and what's expected.
Documenting that using the virsh capabilities output to find the various
values wasn't clear to me until I started poking around. I don't mind
helping with the language/documentation aspects of it - just want to be
sure I have a better picture of what I'm trying to describe!
John