Thoughts on the DMTF SVPC CIM?

[Eric Windisch]

I haven't noticed any discussion here about the SVPC CIM. We've had
mention of DMTF's OVF, but that is just a small part of their
involvement in "cloud standards", or as they're calling, VMAN - The
Virtualization Management Initiative. Another important part of
their initiative is SVPC, an infrastructure management protocol,
building on CIM.

If this is greek to you, I understand it to be, essentially, a
protocol similar to the Sun Cloud API, OCCI, or EC2, but created by
the DMTF and already receiving support by Citrix (Xen), and Microsoft
(HyperV). Citrix/Xen has already released their Kensho project under
the GPLv3, providing backend support for OVF images, and SVPC/CIM for
management. There is also a frontend to the Kensho project, although
I'm not sure if that is free software or not.

This isn't particularly new either, this working group has been around
for a few years already. The following press release has some
preliminary profiles published in 2007:
http://www.dmtf.org/newsroom/pr/view?item_key=70d5d3ba78d39488626f838397a3d1e9812e5d40

I'm not associated with anyone involved. I'm just interested in
sparking some conversation, since this hasn't yet been discussed here,
and has seemed to fly a little bit under the radar.

--
Eric Windisch

[Paulo Calcada]

good stuff, I will read it with real interest.

2009/4/21 Eric Windisch <er...@grokthis.net>

[Rich Miller]

Interestingly enough, I have just gone through a presentation at SAP's
Virtualization Week, presented by Hannes Kuehnemund, SAP LinuxLab (in
Waldorf). He noted that
Challenge
- SLA’s and other services (e.g. SAP Early Watch) are not fully
available when utilizing VMs as the underpinning for SAP landscapes.
- SAP support is not able to check from inside the VM what caused the
situation

The solution he called out:
- SAP has established a standard for Virtual Server Monitoring (based
on DMTF draft) (the SPVC you've mentioned).
- SAP working very with virtualization vendors to implement a virtual
server monitoring
solution with the focus on ease-of-use:“It works out of the box”
- SAP has now made the availability of virtual server monitoring
mandatory prior to a certification by SAP

I'm trying to determine whether this "standard" for the SAP community
is openly available, and where I can get a copy. (If any of you know
anything about this or can locate a description, please let me know.)

When I asked Hannes about the intentions of the SAP wrt to the DMTF
standard, he asserted that they're all for making sure it shows up as
part of DMTF's CIM.

- Rich

On Apr 21, 9:29 am, Paulo Calcada <pcalc...@gmail.com> wrote:
> good stuff, I will read it with real interest.
>

> 2009/4/21 Eric Windisch <e...@grokthis.net>

>
>
>
>
>
> > I haven't noticed any discussion here about the SVPC CIM.  We've had
> > mention of DMTF's OVF, but that is just a small part of their
> > involvement in "cloud standards", or as they're calling, VMAN  - The
> > Virtualization Management Initiative.   Another important part of
> > their initiative is SVPC, an infrastructure management protocol,
> > building on CIM.
>
> > If this is greek to you, I understand it to be, essentially, a
> > protocol similar to the Sun Cloud API, OCCI, or EC2, but created by
> > the DMTF and already receiving support by Citrix (Xen), and Microsoft
> > (HyperV).   Citrix/Xen has already released their Kensho project under
> > the GPLv3, providing backend support for OVF images, and SVPC/CIM for
> > management.  There is also a frontend to the Kensho project, although
> > I'm not sure if that is free software or not.
>
> > This isn't particularly new either, this working group has been around
> > for a few years already.  The following press release has some
> > preliminary profiles published in 2007:
>

> >http://www.dmtf.org/newsroom/pr/view?item_key=70d5d3ba78d39488626f838...

[Bechauf, Michael]

Let me check this. I know that we are doing engineering work with the major virtualization vendors which we do ahead of any real standardization in an open standard like DMTF, but I'm a little surprised by his response that we already had engaged in CIM.

-Michael

[Jeff]

Hello
I'm fairly active in the DMTF's SVPC WG...here's the taxonomy / flow:
CIM= common information model upon which 'most' of the profiles are
based upon.
Virtualization Model= a virtualization model based on CIM and fully
supported and implemented by most industry vendors including Profiles=
instances of CIM for a specific Use CaseMicrosoft, HP, IBM, Sun,
VMWare, EMC, Cisco, etc...Profiles are based on the Virtualization
Model which is actually a pretty good read.
OVF= Open Virtualization Format= Far more than a transport packaging
spec for a VM. OVF 2.0 is being focused on dynamic platform VM
interaction. OVF is based largely on CIM-based 'RASDs' specified in
RAP (resource allocation profiles).

The OVF is definitely something this group should consider?
I realize this is a scratch/sniff of the dmtf and ovf but if I've left
you thirsting for more just visit www.dmtf.org and cull out the
respective tutorials, SVPC WG charter and work register items for OVF?

regards
jeff

On Apr 21, 5:03 pm, "Bechauf, Michael" <michael.bech...@sap.com>
wrote:

[Rich Miller]

Jeff,

I've tried to find information regarding OVF 2.0 efforts, but to no
avail. There are no documents (or search hits) on the DMTF site
regarding the charter/objectives for OVF 2.0. Is there anything to
which you can point me that would provide a sense of the targets for
2.0 and to what degree the OVF 1.1 and 2.0 efforts are different? It
would be much... MUCH ... appreciated, and would go a long way to
making the OVF work more visible and enticing to this effort.

Best,
- Rich

On Apr 22, 8:51 am, Jeff <jewhe...@cisco.com> wrote:
> Hello
> I'm fairly active in the DMTF's SVPC WG...here's the taxonomy / flow:
> CIM= common information model upon which 'most' of the profiles are
> based upon.
> Virtualization Model= a virtualization model based on CIM and fully
> supported and implemented by most industry vendors including Profiles=
> instances of CIM for a specific Use CaseMicrosoft, HP, IBM, Sun,
> VMWare, EMC, Cisco, etc...Profiles are based on the Virtualization
> Model which is actually a pretty good read.
> OVF= Open Virtualization Format=  Far more than a transport packaging
> spec for a VM.  OVF 2.0 is being focused on dynamic platform VM
> interaction.  OVF is based largely on CIM-based 'RASDs' specified in
> RAP (resource allocation profiles).
>
> The OVF is definitely something this group should consider?
> I realize this is a scratch/sniff of the dmtf and ovf but if I've left

> you thirsting for more just visitwww.dmtf.organd cull out the

[jeff wheeler]

Rich et al
The 2.0 are internal WG docs and I should have realized access was
limited.
I'll mention this in today's meeting and seek some presentation / doc
for distribution.
I'll work with the chair on this and post a URL when I've culled out
the salient info.
regards
jeff

> > you thirsting for more just visitwww.dmtf.organdcull out the

[Steve Winkler]

Hi Rich,

Michael and I followed up on your inquiry with our colleagues here at
SAP. The standard to which you are referring is really a set of
monitoring capability requirements that SAP has defined for the
purpose of providing support to our customers. We defined what we
need for this interface, and shared that with the partners we're
working with to ensure that they could meet these requirements.

Does anybody here believe that standardizing this type of Hypervisor
interface would benefit the open cloud?

If you all feel strongly that such an open standard makes sense, we
would be happy to seek your support in driving such an effort.


Cheers,
Steve Winkler
SAP

On Apr 21, 5:03 pm, "Bechauf, Michael" <michael.bech...@sap.com>
wrote:

[Andy Edmonds]

Hi Steve,
The monitoring capability would hugely benefit any cloud provider and their customers where that cloud provider offers its customers automated SLAs. Even more beneficial is if this interface was a standardised one. I know of a number SAP people that are hugely interested in automated SLAs in the context of cloud computing and I myself come from a research project [1] that is headed up by another SAP colleague. I can easily imagine that we collectively would be very interested in collaborating in such an effort.

Regards,

Andy
andy.edmonds.be

[1] http://sla-at-soi.eu

[Rich Miller]

Jeff,

Thank you. In my opinion, anything your chair and the working group
can do to make clearer the targets for OVF 1.1 and 2.0, the better off
we will all be. I know that if the working group were to be willing
to expose some aspects of the efforts, we would not be getting the
kind of frustration I see in Lori MacVittie's blog post on OVF.
http://devcentral.f5.com/weblogs/macvittie/archive/2009/04/21/ovf-a-few-layers-short-of-a-full-stack.aspx

I believe that this bespeaks both the aspirations and the worst fears
of the technical community that is not on the "inside." As a group,
DMTF would do well to manage expectations a bit better. To the degree
we know that OVF is addressing an issue, the community at large can be
helpful, but not try to establish competitors. To the degree that
there are clearly aspects that are not being addressed at this time,
the community is more disposed to attend to those issues.

I hope that the working group sees its way clear to providing that
visibility into OVF.

= Rich

> > > you thirsting for more just visitwww.dmtf.organdcullout the

[Rich Miller]

Steve,

Thank you very much for digging into this. Regarding your question, I
would have to echo Andy Edmonds' response:
This is arguably a successful, multi-vendor approach to a "pre-
standard." Knowing what's worked and is working in that situation
would potentially be very instructive to this group.

We can only hope that this group can, in return, provide insight or
something more tangible to the private effort. Unless I
misunderstand the nature of the "pre-standard", I can't see that there
would be any harm or disruption caused by exposing the specific
approach SAP and it's partners have taken. It would seem like "a win"
for everyone involved.

Best,
- Rich

[Winkler, Steve]

 

Hi Andy,

 

I read through the SLA@SOI documentation this morning.  If I understand it correctly, this seems to be focused at a much higher layer than the work to which Rich was referring.  The SLAs defined by this group appear to be focused on traditional SLAs between businesses for particular business processes, things like perfect order rate, etc.   Since the systems can monitor the business process execution, they can also monitor these types of SLAs.    

 

Business process SLAs are important, to be sure, but the work that we’re talking about below is far more low level.  It’s focused on defining an interface between raw data in VMs and a monitoring solution, and defines a way to expose configuration information, VM runtime information, and host runtime information – things like number of CPUs and the amount of virtual memory paged out by the virtualization platform.  All of this information can be useful when trouble shooting or providing support to our customers. 

 

Are you still interested?  Am I missing something? 

 

Cheers,
Steve

[Andy Edmonds]

Thanks Steve for taking the time!

You might of seen references to full-stack (or  multi-level) SLA management. In SLA@SOI, we are looking at SLA management from the top level, business, straight through the software layer and down into the infrastructure. The SLA may start out in high level business terms but will eventually be translated into the low level infrastructural SLAs (essentially provisioning requests). These SLA hierarchies are then monitored for violations and where one occurs the appropriate action is executed. My own point of view comes from infrastructure, the low level and hence my interest in what you were saying. Everything that you note in your second paragraph is of direct interest to me :-) Additionally, I've been contributing to the OCCI OGF WG, as part of my work in SLA@SOI, and within that group we've seen a need for standardised monitoring interfaces of cloud infrastructure too.

Hope that explains things a little more, albeit some what of an oversimplification. Let me know if you have more questions either here or off list. And in sort - yes I am certainly still interested and I know others within the project will be too! :-)

Andy
andy.edmonds.be