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

Re: [Xen-API] Re: XSDL schemas for Xen virtual machine configurations



Cool!  Then it should be easy to persist a domU's CIM representation
using whatever persistence layer one wants to use, right?

Peace.
Andrew
On Thu, 2006-08-03 at 08:40 -0700, Gareth S Bestor wrote:
> Well, I was going to keep quiet rather than risk forever being
> labelled (and dismissed?) as a "CIM bigot", but ... :-)
> 
> As Mike implies, there is today already a "pseudo-standard" XML based
> format for fully describing a virtual system configuration, namely the
> array of CIM_SettingData that is passed into the DefineVirtualSystem()
> extrinsic method in the DMTF System Virtualization profile. Basically,
> this contains all the important data describing what you want in your
> VM, shoved into a CIM-XML extrinsic method call. The *actual* settings
> of the eventual new VM may differ somewhat, since the virtualization
> platform may apply some internal defaults, etc, but you still
> basically end up with a set of CIM_SettingData objects that fully
> describe the VM, all of which can be translated in a well-defined
> manner to CIM-XML. Whilst we don't pass in any associations defining
> structural relations between the components of the new VM, these are
> generated as part of the DefineVirtualSystem process to tie things
> together and exist as internal CIM objects (aka CIM_Dependency
> subclasses) and have a well-defined CIM-XML representation too.
> 
> 
> I'm not suggesting that we must adopt CIM-XML because it is
> undoubtedly the best format to persist DomU config data - it probably
> isn't the 'best' - but the reality is that we effectively have all the
> data in this specific XML format already, independent of anything
> else, by virtue of the CIM mgmt stuff. And by definition, we - Xen CIM
> folk - are going to have to make sure everything we need to express
> for a DomU config can be expressed via CIM classes, and hence
> representable in CIM-XML, in order for us to do basic CIM-based
> lifecycle management of Xen; ie we're already effectively having to
> invent this wheel, albeit primarily for our CIM mgmt! :-)
> 
> Just something to keep in mind.
> 
> - Gareth
> 
> Dr. Gareth S. Bestor
> IBM Linux Technology Center
> M/S DES2-01
> 15300 SW Koll Parkway, Beaverton, OR 97006
> 503-578-3186, T/L 775-3186, Fax 503-578-3186 
> 
> Inactive hide details for
> ncmike@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx@us.ltcfwd.linux.ibm.com
> 
> 
>                                 ncmike@xxxxxxxxxxxxxxxxxxxxxxx 
>                                 Sent by: xen-api-bounces@xxxxxxxxxxxxxxxxxxx 
>                                 
>                                 08/02/06 07:30 AM
>                                 
> 
>                To
> 
> aball@xxxxxxxxxxxxxxxxxxxxxxx
> 
>                cc
> 
> xen-
> api@xxxxxxxxxxxxxxxxxxx
> 
>           Subject
> 
> [Xen-API] Re:
> XSDL schemas for
> Xen virtual
> machine
> configurations
> 
> 
> 
> On 02/08/06 09:57 -0400, Andrew D. Ball wrote:
> >Cool!
> >
> >You're most welcome to kick this off which whichever type of schema
> you
> >think is appropriate.  I think [without lots of experience to back it
> >up, mind you] that something simple would be fine for now, leaving
> the
> >more complicated contraints to domain logic.
> 
> Please don't ignore the DMTF modelling work that is going on right
> now. CIM 
> technology is not elegant but standard xml schemata are truly horrid -
> there
> are no elegant options.
> 
> CIM schemata are very good a expressing conditions and relationships,
> despite
> their clumsy notation.
> 
> Mike 
> 
> _______________________________________________
> xen-api mailing list
> xen-api@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api
> 
> 
> 


_______________________________________________
xen-api mailing list
xen-api@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.