|
xen-cim
Re: VSManagmentService implementation discussion (was: [Xen-cim] Bridge)
Gareth S Bestor wrote:
>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?
I think Xen is different. The hypervisor is not a service you can stop
/ start. Shutting down xend just disables management - currently
running guests continue to operate with no way to manage them. I agree
we should support start service, i.e. start xend if it is not running,
but I'm a little uncomfortable with stopping xend on stop service.
Perhaps we can implement stop service at a higher level if the need is
there to support it at all, e.g. in the provider itself.
>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.
Looking at the latest System Virtualization Profile (posted by Michael
today), we must support RequestStateChange() on the ComputerSystem
object as this is the only mechanism for state transition.
VirtualSystemManagementService only contains the following extrinsic
methods: CloneVirtualSystem(), CreateVirtualSystemConfiguration(),
DefineVirtualSystem(), DestroyVirtualSystem(),
DestroyVirtualSystemConfiguration(), and ModifyVirtualSystem(). I
agree, as you mentioned above, that it is preferable to invoke methods
on the object itself. So this is good :-).
As far as Power State Profile goes, Novell SMASH project will have an
implementation of this profile. Does it make sense to have that
implementation virtualization aware? That is, if running on virt
platform (Xen) do the right thing? From an implementation perspective
it's not yet clear to me how these various profiles integrate.
Jim
_______________________________________________
Xen-cim mailing list
Xen-cim@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-cim
|
|
|
Home