[Engine-devel] Stable PCI/DEvice addresses

[Andrew Cathrow]

----- 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?





> --
> 
> /d
> 
> Never say "OOPS!" always say "Ah, Interesting!"
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>