[Engine-devel] Stable PCI/DEvice addresses

[Dan Kenigsberg]

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.