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'/>?
Michal