Re: [Xen-cim] Fix some mof files

[Gareth S Bestor <bestor@xxxxxxxxxx>]

>I think the Antecedent property in Xen_HostedComputerSystem should
>remain of type Linux_ComputerSystem.  Something needs to represent /
>implement the hosting computer system and we shouldn't use
>Xen_ComputerSystem provider since it represents the virtual system.  
>Perhaps we can add any virtualization specific requirements to the
>existing Linux_ComputerSystem implementation.  Another possibility is
>creating a new class Xen_HostingComputer system, in which case
>Xen_ComputerSystem should be renamed to Xen_HostedComputerSystem.

The DMTF model has all the lifecycle operations handled by the VirtualSystemManagementService class,
not the individual virtual ComputerSystem class (although there's no reason the latter cannot be added as a hypervisor specific extension...).
In terms of what/how to represent the hosting ComputerSystem, in terms of being DMTF comformant so long as the appropraite
associations are wired correctly - eg HostingComputerSystem - we can pretty much do as we like. The 'problem' (with the model) is that if a
client just goes in and enumerates "CIM_ComputerSystem" they will (indeed must!) get not only the host computer system but also all DomU's too.

Basically, as defined, the System Virtualization model requires a client (either real CIM client or our upcall) to enumerate CIM_ComputerSystem and then
filter out all virtualized system, either by their class (which in the upcall case we know), or by a special property tag (eg a "IsVirtualized" property added to
Xen_ComputerSystem, or by looking at which end of the HostedDependency association the instance occurs).

If we know precisely what host instrumentation will be implemented in the resident Xen system (eg distro specific) then putting a specific CIM_ComputerSystem
subclass as the target (eg IBM Director's IBMPSG_ComputerSystem, SBLIM's Linux_ComputerSystem, Xen_HostedComputerSystem, whatever) is OK, and simple
- that's exactly what I did for the IBM LTC internal providers. But in terms of cross-platform support and generality, if we want to exploit an upcall to populate the Xen_HostedComputerSystem association (rather than manually building it from scratch) then I think the enumerateall-and-filter approach will require the least rework in the long run.


>We should support the intrinsic RequestStateChange() method on
>Xen_ComputerSystem and remove the *VirtualSystem() methods currently
>defined there.  The extrinsic methods could simply be mapped to
>RequestStateChange().  Looking at the latest System Virtualization
>Profile, the only methods now supported on
>VirtualSystemManagementService are CloneVirtualSystem(),
>DefineVirtualSystem(), DestroyVirtualSystem(),
>DestroyVirtualSystemConfiguration(), ModifyVirtualSystem(), and
>PlanVirtualSystem().

Correct. Most of the extrinsic lifecycle methods defined in Xen_ComputerSystem can for the most part just be reworked into a collected RequestStateChange() method instead. For simplicitly and to avoid unnecessary confusion,
I'd recommend removing the old extrinisic methods, even though iti s technically OK for them to be in there as a custom Xen extension...


>BTW, Xen_VirtualizationManagementService should be
>renamed to Xen_VirtualSystemManagementService.

yup.


>The VirtualSystemManagementService methods such as destroy, modify, and
>clone will receive a reference to Xen_ComputerSystem instance.  The
>service can then perform the requested operation via libvirt, extracting
>any info it needs from the instance and its associated objects.

Exacltly. The target DomU info needed by libvirt can be obtained from the key properties in the Xen_ComputerSystem reference/objectpath
that is passed in, mostly likely Name. Failing that, the Xen_VirtualSystemManagementService provider can do a GetInstance() call
on the reference to obtain all the properties of the DomU (eg to get the Id). It rather depends on what we define the key Name property string to
contain.

- 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 04/28/06 10:04 AM

To: "Subrahmanian, Raj" <raj.subrahmanian@xxxxxxxxxx> cc: xen-cim@xxxxxxxxxxxxxxxxxxx Subject: Re: [Xen-cim] Fix some mof files

Subrahmanian, Raj wrote:

> This (minor) patch fixes the following
> - XenComputerSystem derives from CIM_VirtualComputerSystem
> - Some occurences of Linux_XXXX occurrences changed to CIM_XXXX
> occurrences.


I think the Antecedent property in Xen_HostedComputerSystem should
remain of type Linux_ComputerSystem.  Something needs to represent /
implement the hosting computer system and we shouldn't use
Xen_ComputerSystem provider since it represents the virtual system.  
Perhaps we can add any virtualization specific requirements to the
existing Linux_ComputerSystem implementation.  Another possibility is
creating a new class Xen_HostingComputer system, in which case
Xen_ComputerSystem should be renamed to Xen_HostedComputerSystem.

>  
> After seeing some of the code and browsing through the documentation,
> I have a few questions. I have not yet had the opportunity to
> thoroughly study the System Virtualization Profile Document, so please
> bear with me if I am asking something that's already answered elsewhere.
> - Is our goal to have our provider ultimately follow the model
> described in the DMTF System Virtualization Profile Document?


Yes.

> - I am having trouble imagining how the whole thing is going to be
> orchestrated, for instance, I can see how the Xen_ComputerSystem
> provider can control the lifecycle of its VM, but how does the
> VirtualSystemManagementService talk to it or tell it what to do?


We should support the intrinsic RequestStateChange() method on
Xen_ComputerSystem and remove the *VirtualSystem() methods currently
defined there.  The extrinsic methods could simply be mapped to
RequestStateChange().  Looking at the latest System Virtualization
Profile, the only methods now supported on
VirtualSystemManagementService are CloneVirtualSystem(),
DefineVirtualSystem(), DestroyVirtualSystem(),
DestroyVirtualSystemConfiguration(), ModifyVirtualSystem(), and
PlanVirtualSystem().  BTW, Xen_VirtualizationManagementService should be
renamed to Xen_VirtualSystemManagementService.

The VirtualSystemManagementService methods such as destroy, modify, and
clone will receive a reference to Xen_ComputerSystem instance.  The
service can then perform the requested operation via libvirt, extracting
any info it needs from the instance and its associated objects.

Regards,
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