Re: VSManagmentService implementation discussion (was: [Xen-cim] Bridge)

[Gareth S Bestor <bestor@xxxxxxxxxx>]

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

Philosophical question - if you cant
actually see if they are running, how do you really know they are?!  :-)
It reminds me of the classis question about does the refrigerator light
*really* go off when you close the door... :-)

But I see your point. Yeah. Turning
'xen' on and off fully really means destroying whatever DomUs happen to
be running, and I'm not sure we want to go to that extreme. I'm open to
good suggestions. Maybe enable StartService, but only enable StopService
when there are no active DomU's? Any input from XenSource as to whether
they'd like us doing something this radical this from CIM, potentially
on the fly?
  

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

I thought supporting the SMWG  profile's
RequestStateChange()was optional,
but either way, I agree and think supporting this for Xen_ComputerSystem
would be good (ie replace and remove the copies of the VirtualizationMgmtService
extrinsic's).


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

The Power State Profile is certainly
optional at this point, and I'm not sure if we necessarily want to go to
the extent of supporting it too - though no harm in doing so. But as you
point out, the DMTF model isnt terribly clear or consistent about how these
two documented mechanisms to changing a (computer) system's state are supposed
to behave and interact...

- G

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>

05/24/2006 05:10 PM

To	Gareth S Bestor/Beaverton/IBM@IBMUS
cc	Xen-cim@xxxxxxxxxxxxxxxxxxx, Ron Goering/Austin/IBM@IBMUS
Subject	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