WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-cim

Re: [Xen-cim] Fix some mof files

To: "Subrahmanian, Raj" <raj.subrahmanian@xxxxxxxxxx>
Subject: Re: [Xen-cim] Fix some mof files
From: Jim Fehlig <jfehlig@xxxxxxxxxx>
Date: Fri, 28 Apr 2006 11:04:19 -0600
Cc: xen-cim@xxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 28 Apr 2006 10:04:34 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <94C8C9E8B25F564F95185BDA64AB05F60376100C@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-cim-request@lists.xensource.com?subject=help>
List-id: xen-cim mailing list <xen-cim.lists.xensource.com>
List-post: <mailto:xen-cim@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-cim>, <mailto:xen-cim-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-cim>, <mailto:xen-cim-request@lists.xensource.com?subject=unsubscribe>
References: <94C8C9E8B25F564F95185BDA64AB05F60376100C@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-cim-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla Thunderbird 1.0 (X11/20041206)
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

<Prev in Thread] Current Thread [Next in Thread>