11:07 a.m.
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.
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.
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).
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).
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).
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.
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, ...)
Michal