[libvirt] domain XML for tracking libosinfo ID

[Martin Kletzander]

On Thu, Sep 06, 2018 at 10:04:35AM -0400, Cole Robinson wrote:
>On 09/06/2018 09:04 AM, Martin Kletzander wrote:
>> On Wed, Sep 05, 2018 at 03:37:22PM +0100, Daniel P. Berrangé wrote:
>>> On Wed, Sep 05, 2018 at 02:01:42PM +0200, Martin Kletzander wrote:
>>>> On Wed, Sep 05, 2018 at 09:28:52AM +0100, Daniel P. Berrangé wrote:
>>>> > On Tue, Sep 04, 2018 at 03:44:12PM -0400, Cole Robinson wrote:
>>>> > > Right now in virt-manager we only track a VM's OS name (win10,
>>>> fedora28,
>>>> > > etc.) during the VM install phase. This piece of data is important
>>>> > > post-install though: if the user adds a new disk to the VM later,
>>>> we want to
>>>> > > be able to ask libosinfo about what devices the installed OS
>>>> supports, so we
>>>> > > can set optimal defaults, like enabling virtio.
>>>> > >
>>>> > > There isn't any standard libvirt XML field to track this kind of
>>>> info
>>>> > > though, so apps have to invent their own schema. nova and rhev do it
>>>> > > indirectly AFAICT. gnome-boxes does it directly with XML like this:
>>>> > >
>>>> > >   <metadata>
>>>> > >     <boxes:gnome-boxes
>>>> xmlns:boxes="https://wiki.gnome.org/Apps/Boxes">
>>>> > >       <os-id>http://fedoraproject.org/fedora/28</os-id>
>>>> > >       ....
>>>> > >     </boxes:gnome-boxes>
>>>> > >   </metadata>
>>>> > >
>>>> > > I want to add something similar to virt-manager but it seems a
>>>> shame to
>>>> > > invent our own private schema for something that most non-trivial
>>>> virt apps
>>>> > > will want to know about. I was thinking a schema we could
>>>> document with
>>>> > > libosinfo, something like
>>>> > >
>>>> > > <metadata>
>>>> > >   <libosinfo
>>>> > > xmlns:libosinfo="http://libosinfo.org/xmlns/libvirt/domain/1.0">
>>>> > >     <os-id>http://fedoraproject.org/fedora/28</os-id>
>>>> > >   </libosinfo>
>>>> > > </metadata>
>>>> >
>>>> > Yes, I would like to see this standardized under <matadata>.
>>>> >
>>>>
>>>> Me too and what Cole suggested looks fine.
>>>
>>> It occurs to me that we actually need more than just the os-id value.
>>>
>>> When you query devices for a given OS, you'll often be told that multiple
>>> devices are compatible, and the mgmt app can decide which of them to then
>>> use.
>>>
>>> So if we want consistency when later hotplugging, we should make a record
>>> of which devices we decided to use too, so if the mgmt app changes its
>>> preference, we still know what we originally picked.
>>>
>>> eg to express that we use virtio-net and virtio-blk (even if virtio-scsi
>>> was supported by the OS):
>>>
>>>   <metadata>
>>>     <libosinfo
>>> xmlns:libosinfo="http://libosinfo.org/xmlns/libvirt/domain/1.0">
>>>       <os id="http://fedoraproject.org/fedora/28"/>
>>>       <device id="http://pcisig.com/pci/1af4/1000"/>
>>>       <device id="http://pcisig.com/pci/1af4/1001"/>
>>>     </libosinfo>
>>>   </metadata>
>>>
>>> Note, I'm suggesting using an 'id' attribute, rather than naming the
>>> element 'os-id', to be more closely aligned with osinfo schema.
>>>
>>
>> I'm not against that <device id =''/> but it is going to take some
>> effort to
>> properly specify what is really meant by that.  The fact that some
>> device model
>> was chosen for a particular device does not necessarily mean that it is
>> requested as the default.  It only means what is actually encoded in the
>> XML
>> already, that is a particular model for a particular device.
>>
>
>Yeah I'm a bit confused by this as well, it's not exactly clear to me
>how we would use or set XML like that for virt-manager, and how other
>apps would be expected to consume it.
>

That's what I though of when trying to say we need to define the meaning of
that.  What might be meaningful is if the user selects a particular *default*
model for new devices (e.g. disks should be IDE by default) then that option
could be honoured when adding a new device of that type (unless requested
otherwise).  I'm not sure if that's what Daniel meant by that.

>I'll start with the <os id=X/> bit and we can revisit the <device id=X/>
>later
>

Yes.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20180907/2013716c/attachment-0001.sig>