| |
|
 |
|
 |
|
|
|
| |
|
|
xen-cim
Re: [Xen-cim] Latest slide deck for Xen Summit
Gareth S Bestor wrote:
>Find my latest work on the summit presentation attached. The diagram on
>slide 11 does not include CIM_VSSD or recorded RASD - it was getting
>cluttered with these components and their associations. I think the
>diagram illustrates the concept of resource allocation as is, but will
>add some of the finer points if desired.
Sounds OK. Getting the concept of the VirtualDevice <--> RASD <-->
Pool <--> PxDevice
is most important; recorded vs current RASD is secondary, as is the
one VSSD per VM.
>Perhaps we should have 1 slide
>containing a busy diagram that shows the model in action for an active
>vm. It would bring together all of the 'component' diagrams on previous
>slides.
Sure. One big busy slide with most everything for an active VM - with
processor,
memory, disk & NICs - will be visually overwhelming but something that
we can talk
around and point out relationship, as well as giving them the whole
picture in a printed
slide for reference later.
OK, I'll work on putting the 'busy' slide together.
>Gareth - I don't have source for diagram on slide 8. You will take
care of this one?
Will do.
>Currently for demo I've been thinking along the lines of:
>- Connect to cimom and look in Interop namespace for our profiles
>- Follow ElementConformsToProfile to find host (OMC) CS.
>- Look at pools associated with host CS
>- Look at host resources contained in pool
>- Look at virtual resources (and RASD) allocated from pool
>- Enumerate virtual CS running on host CS by follow HostedDependency
>- Define a virtual CS (will have to use cli for this one as none of the
>free GUI clients support embedded instances)
>- Enumerate virtual CS - see new defined but disabled CS
>- Invoke RequestStateChange() on new CS to move to enabled state
>- Pause/unpause via RequestStateChange()
>- ??
sounds OK. I might suggest reordering a bit:
- Connect to cimom and look in Interop namespace for our profiles
- Follow ElementConformsToProfile to find host (OMC) CS.
- Enumerate virtual CS running on host CS by follow HostedDependency
- Define a virtual CS (will have to use cli for this one as none of the
free GUI clients support embedded instances)
- Enumerate virtual CS - see new defined but disabled CS
- Invoke RequestStateChange() on new CS to move to enabled state
* this might be a good point to break out and show what 'xm' shows for
the new DomU
- Pause/unpause via RequestStateChange()
* Suspend. Show how it still exists wrt to CIM model, but not to 'xm'.
Resume
I have not played with suspend lately, was kind of ignoring it until
moving to the new API as it will provide better support. I'm sure some
working code could be hacked up rather quickly.
* destroy vm
Good point. I'll make sure this works :-).
- Look at pools associated with host CS
- Look at host resources contained in pool
- Look at virtual resources (and RASD) allocated from pool
ie cover the major lifecycle ops first, then delve into the pool stuff.
* Can we demo/show the async lifecycle indications somehow too? ie how
a CIMListerer will
automagically get notified when a DomU is
created/started/stopped/destroyed/etc
Hmm, I have not looked into indications at all. If time permits I will
see if I can get something going. No promises.
Jim
_______________________________________________
Xen-cim mailing list
Xen-cim@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-cim
|
|
|
| |
|
Home