|
|
|
|
|
|
|
|
|
|
xen-cim
Re: [Xen-cim] dom0 vs domu vs domDriver
Perhaps... certainly the property is there to be exploited, but I'm not 100% comfortable (yet :-) with enumerating all the differnet roles that a Xen domain can have into a single mutually-exclusive property value, one that must be shared with all the other different virtualization platform's types... In particular, as Dan alluded to on Xen_API, it seems domu vs domdriver vs domstub vs domfoo is more a (dynamic?) capability, or capabilities, that a particular domain can fulfill at a particular time, and therefore not terribly quite suited to a (static) X/Y/Z tag.
Perhaps we can still use this property if there turns out to be fairly discrete (and static) Xen domain types that must be specified at Create time, but even then I think we may still end up needing more dynamic flexibility to associate particular management capabilities with particular domains during their lifetime.
- Gareth
Jim Fehlig <jfehlig@xxxxxxxxxx>
Jim Fehlig <jfehlig@xxxxxxxxxx>
Sent by: xen-cim-bounces@xxxxxxxxxxxxxxxxxxx
09/15/06 05:04 PM
|
|
While reviewing the Virtual System Profile today I was reminded of the
property SystemType in CIM_VirtualSystemSettingData. I'm wondering if
we can use this to describe the purpose of the virtual system, e.g
DriverDomain, HVMStubDomain, etc. I don't like these names since they
are not very descriptive to the casual user but you get the picture.
SystemType is a string property so no restrictions on what goes there.
See section 8.3.2 in Virtual System Profile version 0.7.2.
BTW, I'll have limited to no network access next week :-). I do plan on
participating in the weekly call next Friday.
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
|
|
|
|
|