[Engine-devel] Stable PCI/DEvice addresses

[Dan Kenigsberg]

On Sat, Dec 03, 2011 at 11:47:35AM +0200, Livnat Peer wrote:
> On 12/01/2011 10:41 PM, Dan Kenigsberg wrote:
> > On Thu, Dec 01, 2011 at 02:09:42PM -0500, Andrew Cathrow wrote:
> >>
> >> ----- Original Message -----
> >>> From: "Doron Fediuck" <dfediuck at redhat.com>
> >>> To: "Dan Kenigsberg" <danken at redhat.com>
> >>> Cc: engine-devel at ovirt.org, "Igor Lvovsky" <ilvovsky at redhat.com>
> >>> Sent: Thursday, December 1, 2011 10:52:42 AM
> >>> Subject: Re: [Engine-devel] Stable PCI/DEvice addresses
> >>>
> >>> On Thursday 01 December 2011 16:11:07 Dan Kenigsberg wrote:
> >>>> On Thu, Dec 01, 2011 at 02:06:52PM +0200, Livnat Peer wrote:
> >>>>> Moving this back to list -
> >>>>>
> >>>>> On 12/01/2011 01:49 PM, Dan Kenigsberg wrote:
> >>>>>> On Thu, Dec 01, 2011 at 06:26:16AM -0500, Eli Mesika wrote:
> >>>>>>> Hi guys
> >>>>>>>
> >>>>>>> I need the xml/json format representing the VM installed
> >>>>>>> devices.
> >>>>>>> Livnat asked me to add it to my Wiki
> >>>>>>> http://www.ovirt.org/wiki/Features/Design/StableDeviceAddresses
> >>>>>>>
> >>>>>>> Please feel free to either send it to me or edit the VDSM
> >>>>>>> section adding this info.
> >>>>>>
> >>>>>> I think that it is wrong to document this in this point in
> >>>>>> time. The
> >>>>>> data is a blob, generated by libvirt, copied by Vdsm, and not
> >>>>>> expected
> >>>>>> to be editted by RHEV-M.
> >>>>>>
> >>>>>> If you REALLY want to know, it is simply libvirt's domain xml,
> >>>>>> which is
> >>>>>> well-documented in http://libvirt.org/formatdomain.html.
> >>>>>>
> >>>>>> Dan.
> >>>>>>
> >>>>>
> >>>>> Hi Dan,
> >>>>>
> >>>>> Since i suspect the next requirement on this would be for RHEVM
> >>>>> to parse
> >>>>> the "blob" and enable user to specify addresses i think the
> >>>>> content of
> >>>>> the "blob" should be discussed.
> >>>>>
> >>>>> Otherwise we'll have to support this "blob" format for the sake
> >>>>> of
> >>>>> backwards compatibility and not be able to set a reasonable API
> >>>>> between
> >>>>> the engine and VDSM.
> >>>>
> >>>> The requirement for 3.1 alowed me to define an opaque parameter,
> >>>> with
> >>>> which Vdsm uses the Engine to store the VM device addresses.
> >>>>
> >>>> We "secretly" opted for storing the libvirt domxml because it
> >>>> already
> >>>> contains addresses for just about anything, and would alow us to do
> >>>> even more evil things in the future (I'm thinking about specifying
> >>>> complete boot order, and other things which libvirt long supports,
> >>>> but
> >>>> Vdsm does not). Another reason was that this was a very simple
> >>>> thing
> >>>> to do.  The down side is that this "device-blob" is a bit bloated
> >>>> in
> >>>> size, and if you look deep into it, it has duplicate information on
> >>>> top
> >>>> of Vdsm's "create" verb.
> >>>>
> >>>> We should probably not include the <source> elements in the blob
> >>>> they
> >>>> are very verbose and uninteresting to RHEV-M.
> >>>>
> >>>> If stressed, Vdsm could report only the <devices> element. It could
> >>>> also
> >>>> convert it to json or yaml, compress and encrypt it - but I do not
> >>>> see
> >>>> the point of these transformations.
> >>>>
> >>>> Dan.
> >>>>
> >>> The direction this is taking is for Engine core to be able to parse
> >>> and
> >>> edit libvirt's domxml, while vdsm is agnostic (or partially agnostic)
> >>> to
> >>> the blob.
> >>>
> >>> Is this what we really need? want?
> >>
> >> When we discuss the blob are we talking about just the address part - eg .
> >> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
> >>
> >> or something more?
> > 
> > This is exactly the question. Until today, the blob was just a blob, opaque to
> > the engine, and there was no discussion.
> > 
> > If the engine wants to be able to control and edit the device addresses, we must
> > agree on how to represent the address for each device type, and how to name each
> > device. The simplest solution is to tap on the good work of the libvirt chaps.
> > If we ever want to, it would allow the Engine to do the crazier stuff alluded by
> > Doron - but it does not force us to go down this path, though.
> > 
> > In my original design I imagined the blob to be a complete libvirt domxml. However,
> > I understand the benefits of a more specific "blob". For the feature at hand, it
> > is safe to limit this down to the <devices> element, with its <source> elements
> > stripped, and possibly converted to your data representation language du jour.
> > 
> > Dan.
> > 
> 
> Hi Dan,
> 
> I understand why pass-through of the domxml is appealing, as it reduces
> work for the current feature, it is also enabling us easily to support
> all type of device addresses that are supported by libvirt.
> 
> What i like less is the format, I rather not use a verbose xml for this
> but use JSON as we have in several other places in the engine.
> 
> The next cycle on this feature is to expose the ability to edit
> addresses by the user, and for that we'll need to manipulate the domxml
> in the engine - less fun.
> 
> So although it is more work for us now i rather get the device section
> in a JSON format.

I'm not sure I understand why xml->json conversion is more fun to do in
Vdsm than in Engine; I don't see it as a difficult step either way.

The problem is that we have an already-well-defined interface for
device naming and addressing (libvirt's). Inventing another one, even if
it is only a straight-forward xml-to-json conversion, would inevitably
add doubts and places for bugs.

> 
> BTW - Is there a chance libvirt will support JSON format in the future
> for describing the VM? then we can use the format they suggest for this
> and it can be a JSON pass-through in the future ;)

It has been years since I've touched infinitesimal probabilities, so I
shall leave this question to a libvirt Daniel.

Dan.