|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-cim] Requirements and priorities for SLES10 SP1
In terms of the minimal set of required CIM classes prescribed by the DMTF System Virtualization model, I expect all can be implemented via the new Xen-API, and hence can be run on a remote proxy. However, the DMTF SV profile also has some loose dependencies/interactions with other DMTF CIM profiles, eg base server profile (for host resource mgmt), SMIS block device profiles (for managing host disk storage), network profiles, power management profiles, etc. So for a CIM client to have access to the *full* richness of managing a virtualization-capable host and its various resources - some of which will be virtualized/allocated to VMs - the mgmt app will at times need to interact with non-System Virtualization classes/CIM providers, some of which may or may not be 'remoteable'. As a specific example, Xen allows dedicated assignment of PCI slots to VMs, so at some point we'll be adding to Xen-CIM the respective CIM classes for PCI slot 'pools', RASDs, and pass-thru virtual PCI slots assignment . However, a mgmt app will probably be more interested in knowing and assigning what is *attached* to each PCI slot to a VM, eg a DVD drive. To perform such an informed assignment the mgmt app will need to explore various host-side system resource CIM classes; ie exploit host information not necessarily exposed via the Xen-API. There is also nothing in CIM itself that dictates that all providers for managing a host and its resource must be able to run remotely from a proxy, that is purely a function of whether the underlying system resource mgmt api's have a lower-level remote interface. Indeed, in a lot of cases where there is no current remote mgmt interface for managing a host resource/service, CIM itself can be considered a means to support (standardized) remote management! The ability today to expose a full suite of proxy CIM providers to enable everything we may want to do when managing a Xen host is basically only as feasible as it is today to fully manage a Xen host without ever resorting to telnet/ssh. Whilst the Xen-API may enable everything we need in terms of assigning the primitive host resources to a VM and managing the VM's lifecycle, an mgmt app will likely want to do more in terms of host resource discovery, host (and inband guest) resource monitoring, etc which I would probably consider outside the scope of a pure Xen-API, and which may not today have their own remote mgmt interface. Hope that helps clarify. Like I said earlier, bypassing Xen-API is to be avoided at all costs, and for our Xen-CIM providers themselves there is no foreseeable reason to do so. But other CIM classes (for host mgmt) which may be prerequisites for full mgmt support may not be runnable for a proxy. - Gareth
Inline... On 12/21/06 11:35 AM, "Gareth S Bestor" <bestorga@xxxxxxxxxx> wrote: >...Having the CIM providers go around the API would be bad for portability and >for supporting various use cases in which CIM is required, but not within >each instance of Dom0. To clarify, I expect there will be some mgmt needs for the Xen-CIM mgmt interfaces that are not Xen/hypervisor specific and therefore likely not to be exposed thru Xen-API. In particular, the DMTF SV model does have some CIM_Dependency hooks into host system resource data, certain metrics about specific virtual device utilization (eg DomU memory) may require going inband, etc. So its not so much going around the API, but rather the info needed is probably outside the scope of a pure Xen-API. For now I believe everything we need for the CIM classes we've implemented is pretty well covered (in principle) by Xen-API, and if anything comes up missing we'll certainly look into whether it can be/is appropraite to add to Xen-API. But I cannot categorically state that 100% of the (generic) virtual system managabiity functions eventually expressed on the CIM interface will either [a] be wholly a subset of the Xen-API functionality, or [b] otherwise have their own remote interface. This I don’t understand. If there’s something missing, it needs to be added. This is presumably an iterative refinement... So it may be the case that a remoted CIM mgmt interface to a Xen box (or other hypervisor platforms for that matter) may have <100% CIM manageability richness of a local CIM mgmt interface. Again, this will probably come down to how much of Linux itself is remotely (non-CIM) manageable as opposed to anything lacking in Xen-API per se. In some cases needed raw Linux data/mgmt control knobs may have remote interfaces too, but I've certainly not driven down thru *all* the DMTF SV classes proposed - and likely to come down the line - to understand whether *everything* can be offloaded and managed remotely. This is worrying. We, Xen-CIM, still have to learn to crawl (on the box) before we can run! :-) IMO, the baseline requirement should be that the CIM providers can run both locally and remotely. Simon - Gareth  Simon
Crosby <simon@xxxxxxxxxxxxx>Simon Crosby <simon@xxxxxxxxxxxxx> Sent by: xen-cim-bounces@xxxxxxxxxxxxxxxxxxx 12/19/06 06:54 PM 
To
cc
Subject
_______________________________________________ Xen-cim mailing list Xen-cim@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-cim
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |
