[libvirt] [PATCH for 1.2.7 1/8] Introduce domain_capabilities

Michal Privoznik mprivozn at redhat.com
Wed Jul 2 16:07:12 UTC 2014


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




More information about the libvir-list mailing list