|
>1. Should we support start/stop service? Currently these methods
>start/stop xend - seems like suicide and not nice for other management
>tools :-). I think we should mark these "not supported" for the time.
The CIM_Service superclass includes a StartService and StopService methods, to basically turn said service on and off. I dont have a strong opinion, but I guess if there is a way to turn a host system's Xen virtualization "on" or "off" then we should probably be thorough in implementing the CIM model and support it. Of course, starting/stopping xend will cause serious problems, so whilst it may be 'supported' it certainly wouldn't be 'recommended'....
I look at it this way - NFS is an exposed host's service too and being able to turn it on and off is a legitimate management function. Is Xen so different? [that's an honest question, not a statement].
Thoughts?
>2. How to handle the embedded instance parameters in various extrinsic
>methods? When I first noticed these parameters in the profile / mof I
>thought of using OpenWBEM's mof compiler library - assuming the encoding
>of embedded instances was mof. However this approach in not cimom
>agnostic and thus not an option for this project. How do you envision
>handling the embedded instances in CMPI? Also, I read Appendix H of
>
> http://www.dmtf.org/standards/published_documents/DSP0004V2.3_final.pdf
>
>and it is not clear how one specifies which encoding is in use. Does an
>implementation have to support both encodings?
I've added a custom parser to our internal Xen_ComputerSystem and Xen_VirtualizationManagementService method provider implementation of CreateVirtualSystem that will in the array of embedded ResurceAllocationSettingData instances (encoded as MOF-formatted text in a string) to create the required CIM objects for subsequent processing by CreateVirtualSystem(). Normally, this decoding is done by the CIMOM and the provider is presented with the CIM objects as the input args to the method, and is completely unaware that is was in fact encoded string data being passed in from the CIM client. Unfortuantely, OpenPegasus doesnt handle embedded instances in method param string's, hence the need for a custom parser...
I'll finish scrubbing this newer code and check it into hg - what is missing is support for CIM-XML encoded string [the DMTF spec allows embdeed instances to be encoded as either CIM-XML of MOF formatted data]. Hopefully when the major CIMOMs get around to fully supporting embedded instnaces/objects everywhere that they can be used we can remove this workaround code (presently most CIMOMs only have this support when dealing with passing back CIM indications to subscribers, which contain embedded instance data).
>3. We talked about implementing RequestStateChange() intrinsic method in
>Xen_ComputerSystem. Should we implement the corresponding extrinsic
>methods in VirtualSystemManagementService or just map them to
>appropriate RequestStateChange? For example, should
>PauseVirtualSystem() just call RequestStateChange("Paused") on the
>referenced Xen_ComputerSystem or provide an implementation?
I initially had the lifecycle operations - Start/Stop/Pause/Suspend/Resume - on the Xen_ComputerSystem itself early on in the development of the IBM LTC providers itself as a personal preference (fewer classes that had to be implemented) and the fact there was so much churn about this in the DMTF WG at the time :-) But in the formal DMTF model all the lifecycle stuff now officially lives in the VirtualSystemManagementService; duplicating support for it in Xen_ComputerSystem is optional (and not prescribed by the DMTF). Personally, I kinda like having to be able to control an object by methods on the object itself, rather than having to go off to a service somewhere, but for DMTF conformity we should probbaly just to the lifecycle ops in VirtualSystemManagementService and drop them from Xen_ComputerSystem just so that there is no confusion (and risk mgmt clients being built not using the one always guaranteed to be present).
As for RequestStateChange(), this does exist in the Xen_ComputerSystem. I need to check with Michael (DMTF VS lifecycle owner) if supporting this is method mandatory or optional, bust as described in section 9.3 of the "System Virtualizetion Profile" doc, the state changes supported by this extrinsic will map pretty much directly to the extroinsic lifecycle methods in VirtualSystemManagementService.
Also, we should consider whether or not to also implement the optional Server Power State profile; ie RequestPowerStateChange() in Xen_ComputerSystem too. Also from the "System Virtualizetion Profile" doc:
A virtual computer system can be in one of several states. The intrinsic RequestStateChange() operation may be used on an instance of CIM_ComputerSystem representing a virtual system to effect virtual system state changes. If the Server Power State Profile is implemented by a virtualization platform instrumentation, alternatively the RequestPowerStateChange() method of the CIM_PowerManagementService may be used.
As for the implementation question you asked, my personal preference would be to have the actual DomU lifecycle change code located in with the Xen_ComputerSystem provider code, and have VirtualSystemManagementService make upcalls as necessary to these methods, rather than have all this code located externally in the latter provider, or worse still, duplicated in both. But that's just a purely aesthetic preference of mine and implementation-wise is doesnt matter which provider is calling which to do the actual grunt work.
>4. Some of the extrinsic methods are going to be quite messy to
>implement I believe. DefineVirtualSystem() for example is overloaded.
>The implementation has to parse through all of the embedded resource
>instances, supply defaults for required resources that were not
>provided, supply default properties for resources provided but no
>property value provided, etc. How does the implementation report a
>reasonable error in the event something fails in this process?
Yes, it *was* rather messy when I implemented CreateVirtualSystem (now DefineVirtualSystem), as you will see... :-) Yes, reporting errors back is a problem, mainly due to the lack of good error handling in CIM/CMPI. There is work underway in the DMTF and the OpenGroup working on CMPI2.0 to define better ways to return errors. In the mean time I think we will have to do the best we can, and any error codes on failures that we get back from libvirt we can put into the (optional) error string that gets passed back to the client along with the existing limited set of predefined CIM error codes.
Defining a general subset of typical generic error codes - especially for DefineVirtualSystem, ActiviateVirtualSystem, etc is probably something the DMTF VS WG should think about...
>5. Job control. Currently no support for job control in the providers.
>Does CMPI have thread support? (Obviously I need to spend some time in
>the CMPI spec :-)). We will need some generic job control support for
>the various services that potentially return job IDs
>(VirtualSystemManagementService, ResourcePoolConfigurationService). We
>can just go with synchronous support in the short term.
Yup. There's no job control support in the current providers. But as soon as we want to support any long running operations - migration and suspension of large DomUs come to mind - that could potentially exceed the usual CIM client timeouts then we will have to open the job control can of worms... :-|. Like you say, for now I think we have bigger fish to fry, so lets just include the necessary additional output param in the extrinsic methods and set it to NULL.
CMPI does have support for thread (see the lifecycle indication provider Xen_ComputerSystemIndication.c for an example).
- 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
 Jim Fehlig <jfehlig@xxxxxxxxxx>
Jim Fehlig <jfehlig@xxxxxxxxxx>
Sent by: xen-cim-bounces@xxxxxxxxxxxxxxxxxxx
05/19/06 10:12 AM
|
|
Gareth S Bestor wrote:
> Sorry. I wasnt able to make the call this morning (pity, we could've
> used my conf # again by the sounds of it! :-)
> How'd it go?
>
We didn't spend much time on the call. Talked about the SVPC f2f
briefly. Raj is working on the associations he mentioned in a previous
post. I have moved on to the management service.
I did have some questions for you regarding implementation of
VirtualSystemManagementService.
1. Should we support start/stop service? Currently these methods
start/stop xend - seems like suicide and not nice for other management
tools :-). I think we should mark these "not supported" for the time.
2. How to handle the embedded instance parameters in various extrinsic
methods? When I first noticed these parameters in the profile / mof I
thought of using OpenWBEM's mof compiler library - assuming the encoding
of embedded instances was mof. However this approach in not cimom
agnostic and thus not an option for this project. How do you envision
handling the embedded instances in CMPI? Also, I read Appendix H of
http://www.dmtf.org/standards/published_documents/DSP0004V2.3_final.pdf
and it is not clear how one specifies which encoding is in use. Does an
implementation have to support both encodings?
3. We talked about implementing RequestStateChange() intrinsic method in
Xen_ComputerSystem. Should we implement the corresponding extrinsic
methods in VirtualSystemManagementService or just map them to
appropriate RequestStateChange? For example, should
PauseVirtualSystem() just call RequestStateChange("Paused") on the
referenced Xen_ComputerSystem or provide an implementation?
4. Some of the extrinsic methods are going to be quite messy to
implement I believe. DefineVirtualSystem() for example is overloaded.
The implementation has to parse through all of the embedded resource
instances, supply defaults for required resources that were not
provided, supply default properties for resources provided but no
property value provided, etc. How does the implementation report a
reasonable error in the event something fails in this process?
5. Job control. Currently no support for job control in the providers.
Does CMPI have thread support? (Obviously I need to spend some time in
the CMPI spec :-)). We will need some generic job control support for
the various services that potentially return job IDs
(VirtualSystemManagementService, ResourcePoolConfigurationService). We
can just go with synchronous support in the short term.
Jim
_______________________________________________
Xen-cim mailing list
Xen-cim@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-cim
_______________________________________________
Xen-cim mailing list
Xen-cim@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-cim
|
Home
