Re: [PATCH] domaincaps: Expose UEFI capability

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxx>

Tested-by: Cole Robinson <crobinso@xxxxxxxxxx>
Acked-by: Cole Robinson <crobinso@xxxxxxxxxx>

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

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list




[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]