Re: [libvirt] [PATCH] domaincaps: Expose UEFI capability
On 09/16/2014 11:35 AM, Michal Privoznik wrote:
On 16.09.2014 17:11, Cole Robinson wrote:
> On 09/16/2014 09:44 AM, Michal Privoznik wrote:
>> As of 542899168c38 we learned libvirt to use UEFI for domains.
>> However, management applications may firstly query if libvirt
>> supports it. And this is where virConnectGetDomainCapabilities()
>> API comes handy.
>>
>> Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
>
> Tested-by: Cole Robinson <crobinso(a)redhat.com>
> Acked-by: Cole Robinson <crobinso(a)redhat.com>
Thanks. I'll push this one shortly.
>
> So this exposes that qemu + libvirt have the required support to use OVMF.
>
> The other bit virt-manager would like is to know the paths to the OVMF
> binaries. Preferably with some way to tell if they actually exist on disk,
> which might just be hiding them from the XML if they aren't found, or an extra
> XML property.
>
> As you mentioned in the virt-tools-list email, you probably don't need to
> expose the vars template file path, and just the OVMF binary path.
>
> Thoughts on what the XML might look like? Doesn't seem like there's any
> existing precedence in domcapabilities schema
Correct. domcapabilities is not very mature atm. With this patch, its output
should look like this:
<domainCapabilities>
<snip/>
<os supported='yes'>
<loader supported='yes'>
<enum name='type'>
<value>rom</value>
<value>pflash</value>
</enum>
<enum name='readonly'>
<value>yes</value>
<value>no</value>
</enum>
</loader>
</os>
<devices/>
</domainCapabilities>
How about introducing <nvram/> under the <os/> (like it is in the domain
XML)?
Something like the following:
<os supported='yes'>
<loader supported='yes'>
<enum name='type'>
<value>rom</value>
<value>pflash</value>
</enum>
<enum name='readonly'>
<value>yes</value>
<value>no</value>
</enum>
</loader>
<nvram supported='yes'>
<value>/usr/share/OVMF/OVMF_VARS.fd</value>
<value>/other/files/from/libvirtd.config</value>
...
</nvram>
</os>
As you've probably guessed, the <nvram/>'s <value/> would repeat
itself for
every VARS file known to libvirt. Or should we enclose these into an <enum/>
and make it child of the <nvram/>? What should the enum be called then? Or
even better - shall the <nvram/> be turned into <enum name='nvram'/>?
Yeah that format looks fine, but I'd expect we'd list <loader> values and
not
nvram. Theoretically you could have multiple OVMF binaries map to the same
nvram template, but not the other way around. Also template is the
uninteresting bit from the tool's perspective, since libvirt will fill it in
for us.
- Cole