VMware steps into the cloud

[Reuven Cohen]

I'd like to personally welcome VMware to the cloud.

Today VMware announced its stand-alone ESXi hypervisor will be
available at no cost. ESXi 3.5 update 2, available today, meets the
criteria for mass cloud deployments: (1) ease of use and (2) maturity
and stability now having been 'battle tested' for six months with
customers. The leading server manufacturers have all embedded VMware
ESXi, including Dell, Fujitsu-Siemens, HP, IBM, and NEC.

This is the first major step for VMware in the cloud computing scene.
Historically VMware has focused on server consolidation and test / dev
and has priced their products accordingly. By making the underlying
hyper visor free they effectivily enable cloud providers with the
ability to utilize ESXi in their massive cloud server deployments
while also helping keep their costs competitive with other cloud
providers such as Amazon who utilize Xen.

You can download ESXI from: http://www.vmware.com/products/esxi/

--
--

Reuven Cohen
Founder & Chief Technologist, Enomaly Inc.

blog > www.elasticvapor.com
-
Get Linked in> http://linkedin.com/pub/0/b72/7b4

[William Newport]

They have been doing this for a while, now no? This is dangerous in my
humble opinion because basically this is the new BIOS owned by one
company. Virtual images built within this hypervisor will only run on
this hypervisor. Different hypervisors are basically using different
machine definitions and this will cause lock in as you cant move to a
different hypervisor easily.

We need a standard open source virtual machine specification that can
be implemented by all the major hypervisors to avoid this mess.

Billy Newport
IBM eXtreme Scale | http://www-306.ibm.com/software/webservers/appserv/extremescale/

[Khazret Sapenov]

 

On Mon, Jul 28, 2008 at 12:23 PM, William Newport <bnew...@mac.com> wrote:

They have been doing this for a while, now no? This is dangerous in my
humble opinion because basically this is the new BIOS owned by one
company. Virtual images built within this hypervisor will only run on
this hypervisor. Different hypervisors are basically using different
machine definitions and this will cause lock in as you cant move to a
different hypervisor easily.

We need a standard open source virtual machine specification that can
be implemented by all the major hypervisors to avoid this mess.

Billy Newport
IBM eXtreme Scale | http://www-306.ibm.com/software/webservers/appserv/extremescale/

 

Billy,
No worries :)
There's already such effort, called Project Kensho
quote:
"... Citrix Systems, Inc ...
today announced "Project Kensho," which will deliver Open Virtual Machine Format (OVF) tools that,
for the first time, allow independent software vendors (ISVs) and enterprise IT managers to easily create hypervisor-independent,
portable enterprise application workloads.  These tools will allow application workloads to be imported and run across Citrix XenServer™,
Microsoft Windows Server 2008 Hyper-V™ and VMware™ ESX virtual environments.  "

source:
http://www.citrix.com/English/NE/news/news.asp?newsID=1679371&ntref=hp_article_headlines_US

Another thing to consider is replacement of Diane Greene with Paul Maritz (worked 14 years for Microsoft and heavily involved in cloud computing later),
which is also a strong indicator of the move, besides their official 5 stage roadmap (Separate, Consolidate, Aggregate, Automate, Liberate) to compute clouds on and off premise.

Also interesting to see VMware's  financial results for 2nd quarter 2008
( http://www.vmware.com/company/q208highlights.html), I'll leave its interpretation up to you.

[Reuven Cohen]

OVF attempts to address this need for a cross platform VM format.
VMware, Xen and Microsoft's hyperV all support this format giving
users the ability to fairly easily move among various virtualization
vendors.

As for whether or not VMware has been involved in cloud computing, I
don't know of any major cloud deployments using VMware.

Reuven

On Mon, Jul 28, 2008 at 12:23 PM, William Newport <bnew...@mac.com> wrote:
>

--
--

www.enomaly.com :: 416 848 6036 x 1
skype: ruv.net // aol: ruv6

[Ian]

We're using both VMware and Xen in our cloud environment (www.skytap.com) -
I think we're the only one with VMware support. We think that vendor lock-in
will be an issue for customers, so it's important to support all
hypervisors. Our customers are asking for the ability to upload and download
VMs from the cloud to in-house systems once they are done with development
and testing - most are currently running on VMWare, so supporting a standard
ESX hypervisor is a key requirement for them

-Ian

[James Broberg]

I will have to try ESXi out for myself.. I wonder what features are
missing? I hope the API support is still there, and live migration.

[Ron Leedy]

I went to a presentation were both a Xen engineer and VMWare engineer
talked. There seemed to be a gentlemen's agreement that going forward that
API for controlling VM from any vendor would be standard. Meaning that you
pick your hypervisor (from MS, Xen, VMWare) and be able to control a
container from any of them; even multiple containers from different vendors
on the same hypervisor.

Don't know how real this will be or if any of them will hold to doing it. I
am sure Xen and VMWare have more to gain and more reliable into following
standards than MS. We have seen MS's standards.

-Ron

[Igor Edelman]

When it comes to virtualization and the techniques deployed to achieve (in this case) partitioning one often discusses full virtualization (VMware VI3.x), para-vitualization (Citrix’s Xen), and container or O/S virtualization (a la Parallels - Virtuozzo). Several vendors realize that the Hypervisor is a commodity and are providing management platforms that allow the management of VM's of many "flavors" E.g. BinaryKarma - Fuild VM or DynamicOps. Open Virtual Machine Format (OVF) will help to increase function compatibility. At this point, I see the management platforms working with API’s and/or native management interfaces to allow for a global view and ease of management. However, I don’t suspect that we will have a real push from any of the hypervisor vendors to go beyond that point too fast.   Igor --- On Mon, 7/28/08, Ron Leedy <rf...@speakeasy.net> wrote:

[Paul Renaud]

This is why as a community we have to pressure all vendors to build out management standards around WS-Management.  WS-Man can and should become the SNMP of the cloud as it was, gee, designed to be used for the management of web services. 

 

Case in point it the VM control issue in this thread.  There already is a basic profile for managing VMs using WS-Man from the DMTF.  It currently primarily provides visibility into resource utilization in the VMs and can readily be extended to provide the missing control functionality. The protocol is object oriented, secure, and XML-based, so extending the standard for this purpose can be both easy and readily standardized.

 

The last thing we want or need is yet another API for management purposes - especially when there is a perfectly good one ready to be used with broad support from W3C, DMTF, OASIS, and all the major vendors. 

 

At a network level, we wouldn't accept a new vendor API for managing routers - we would pressure the vendor to publish their MIB so that we could leverage our investments in management applications, monitoring and analysis tools, reporting, etc.  Nor at a database level would we accept a new vendor API for managing databases - we would pressure them to define a SQL-compatible API.  Why wouldn't we do the same in a cloud?

---

From: cloud-c...@googlegroups.com [mailto:cloud-c...@googlegroups.com] On Behalf Of Igor Edelman
Sent: July 29, 2008 12:07 AM
To: cloud-c...@googlegroups.com

[Karl Austin]

Reuven Cohen wrote:
<snip>

> This is the first major step for VMware in the cloud computing scene.
> Historically VMware has focused on server consolidation and test / dev
> and has priced their products accordingly. By making the underlying
> hyper visor free they effectivily enable cloud providers with the
> ability to utilize ESXi in their massive cloud server deployments
> while also helping keep their costs competitive with other cloud
> providers such as Amazon who utilize Xen.
>
> You can download ESXI from: http://www.vmware.com/products/esxi/
>

The only problem I see, would be their license terms:

VMware grants you a nonexclusive, non-transferable license, without rights
to sublicense, to (i) install or have installed a single instance of the
Software and each Licensed Additional Module on a single Server, unless
permitted to have multiple instances on a single Server or to have multiple
instances on multiple Servers by the payment of applicable license fees
(whether such fees are based on a per Processor, a per Virtual Machine, a
per user or any other VMware approved licensing model); (ii) use the
Software and each Licensed Additional Module solely for information
processing and computing purposes, including the hosting of computer
application-based services from a Virtual Machine and provision of such
services via an internal or external network, provided such services may not
consist of services to a third party that provide primarily computing or
processing power (such as utility computing or grid computing) or any
computer application-based service that is traded, rented, leased or sold on
a Virtual Machine basis; and (iii) use and reproduce the VMware Virtual
Infrastructure Client Software or VMware WebAccess (in object code form
only) for the purposes of installation and operation on an unlimited number
of your own internal computers or terminals solely for the purpose of
accessing the Server on which the Software is installed.;

That's going to restrict what a lot of people are doing/wanting to do (point
ii), because they don't want to loose their service provider licensing
revenue, where it's priced per VM instance per month.

Cheers,

Karl

[Kristi Schultz]

There's already a well-defined standard for managing virtual systems in
CIM. Why not use that as the base model? Extend that as needed for clouds
and add RESTful web service access.

Kristi Schultz - Internet: kri...@us.ibm.com
STSM - Blue Cloud Ensemble Management
(507)253-2177 t/l 553-2177 Fax: (507)253-0424
----------------------------------
"Give the customer more than he expects."
"The more you laugh, the better things are."
[Butch Stewart]

[Khazret Sapenov]

I agree with Kristi and also want to add that along with the traditional things, like Web services and queued messaging, Microsoft's WCF adds support for RESTful communication, RSS/ATOM, and an interesting option called the WCF Line-of-Business Adapter SDK (see major layers of the Windows Communication Foundation (WCF) architecture at http://msdn.microsoft.com/en-us/library/ms733128.aspx ).

 

Using mentioned tools it is pretty easy to wire Hyper-V's WMI and remote management interface.

[Ray Nugent]

Karl, your right on the money here. In fact ALL vendors are going to have this issue. The Cloud business model flies in the face of old school enterprise revenue model while the sales model does not change a whole lot. Same cost of sales, lower revenue and open source as competition. A couple if years out enterprise software is not going to be a fun business...

Ray

[Ian]

It does support the API. Live migration is available with the Virtual
Center licensing packages as it was before.

[Reuven Cohen]

I would be interested in hearing some real world experiences with Live
migration. Mine haven't been very good.

Reuven

[Chris Sears]

On Tue, Jul 29, 2008 at 1:21 PM, Reuven Cohen <r...@enomaly.com> wrote:

I would be interested in hearing some real world experiences with Live
migration. Mine haven't been very good.

The joke that I've heard is that VMotion (VMWare's live migration) was mainly implemented for the VMWare sales guys to impress customer executives at presentations. In production it doesn't actually get used nearly as much as you would think.

> This is dangerous in my humble opinion because basically this is the new BIOS owned by one company

> - Billy Newport

I don't think ESXi is a new BIOS. My underrstanding is that there's a bit of flash memory or an SD card added to the motherboards of the servers that the BIOS can now see as a boot device. The BIOS ins't replaced with ESXi. VMWare has the server manufactuer load ESXi into this storage and you (the server buyer) then have ESXi as a OS boot option without ever having to install it. It's really just a way to one-up Microsoft since most people buying Windows Server 2008 will be getting Hyper-V for free.

I guess you could technically put another OS on that storage... or hide malware. And how often do you think people with apply patches or security updates to the ESXi image hiding inside their servers? Probably not ever. Lots of interesting possibilities.

Sort of reminds me of how desktop PCs come with all kinds of crapware applications that people hate. What would you call that... a crapware hypervisor... a crapervisor? (Awesome, no hits... http://www.google.com/search?q=crapervisor  I offically invented the term just now.)

 - Chris

[William Newport]

No

What I meant was, traditionally the BIOS insulated the operating system from the hardware (at least in the good old days) or provided enough function to allow a 'real' operating system to boot. The hypervisor does the exact same thing for a virtual machine. It abstracts the real hardware and makes it standard so the operating system in the VM can boot with 'well known' virtual processor, network, storage cards etc. It's in this regard that the hypervisor virtual machine definition is similar to a BIOS and each hypervisor has a different definition of those virtual devices.

Billy Newport

IBM eXtreme Scale | http://www-306.ibm.com/software/webservers/appserv/extremescale/

[Ormond Merino]

Hello all,

I am the primary hardware virtualization engineer at my employer, and I can attest that we use Vmotion, and if implemented properly, is very useful and reliable. I (and many others in the community) use it in every VMware implementation. Live migration technologies (Vmotion,Xenmotion, etc) will be a key tool used to get us to the 100% dynamic, fully automated datacenter. This allows us to commoditize hardware, and shift processing power from underutilized workloads to those struggling for resources - all without and guest downtime.

VMware is actually not the first vendor to put their hypervisor on a flash chip and OEM it with servers. Citrix has done the same with XenServer, and I imagine Microsoft will with Hyper-V. Phoenix is, however working on using their BIOS to  bootstrap at a hypervisor.


...ormond

[Paul Renaud]

As Kristi points out, WS-Man already has a great start as the baseline management protocol to use for all SaaS applications because of the existing standardized CIM profile for Virtual Machines and the well established method for binding CIM to WS-Man via XML-CIM bindings.

 

There is no need to add anything to WS-Management to make it RESTful.  The basic underlying protocols within WS-Man such as WS-Transfer and WS-Addressing are also clearly RESTful (especially when used in an anonymous reply mode), and if you can believe (as many do) that SNMP is a RESTful architecture even with GET Next state-oriented semantics within the protocol, then WS-Man is equally RESTful.  Most practical management protocols (such as SNMPv2 and WS-Enumerate) require some degree of session state to deal with management of large scale resources.

 

Most SaaS and in general cloud implementations have focused on the features in their service interface but do not provide a separate WS management interface for monitoring the state of resources consumed or provided by the service, events & status relating to the service, service performance or assurance, etc.  Some do a better job providing an interface for service provisioning - especially the ones that grew out of a grid-forum-style batch job heritage. 

 

The Windows Communication Framework referenced by Khazret provides a lot of advanced features such as reliable queuing that historically have not been as important on the management interface as they are on the service interface.  SNMP is immensely powerful and widely used precisely because it is not overloaded by mechanism (in contrast to CMIP).

 

SaaS to really become mainstream needs (a) to separate the management interface from the service interface, and (b) use a widely accepted and simple to implement & use protocol such as WS-Man for that management interface. 

 

Are there any SaaS applications out there that already do this?  I've yet to find any but this space is growing rapidly.

---

From: cloud-c...@googlegroups.com [mailto:cloud-c...@googlegroups.com] On Behalf Of Khazret Sapenov
Sent: July 29, 2008 10:10 AM
To: cloud-c...@googlegroups.com
Subject: Re: VMware steps into the cloud

[William Newport]

Ormond,

Nice to meet you. Can you talk about plans or opinions on using a standard virtual machine definition?

Thanks

Sent from my iPhone

[Dave Kramer]

Rackspace has VMWare support ....Don't look at mosso .... Look at Rackspace hosting services ....
 
"HT"

Dave "HT" Kramer
ht_k...@hotmail.com
972.636.5445

---

[Khazret Sapenov]

On Tue, Jul 29, 2008 at 8:53 PM, Dave Kramer <ht_k...@hotmail.com> wrote:

Rackspace has VMWare support ....Don't look at mosso .... Look at Rackspace hosting services ....
 
"HT"

Dave "HT" Kramer
ht_k...@hotmail.com
972.636.5445

 

 

How quickly all changes :)

quote:

"Hosting providers offering virtual servers could be barking up the wrong tree, according to Rackspace. Virtualisation is not yet ready for the big time, and is unlikely to save its users money, the hosting company claimed. "

source:

http://www.techworld.com/opsys/news/index.cfm?newsid=9788

[Stuart Charlton]

On 29-Jul-08, at 6:23 PM, Paul Renaud wrote:

There is no need to add anything to WS-Management to make it RESTful.  The basic underlying protocols within WS-Man such as WS-Transfer and WS-Addressing are also clearly RESTful (especially when used in an anonymous reply mode), and if you can believe (as many do) that SNMP is a RESTful architecture even with GET Next state-oriented semantics within the protocol, then WS-Man is equally RESTful.  Most practical management protocols (such as SNMPv2 and WS-Enumerate) require some degree of session state to deal with management of large scale resources.

That's not really true.  

SNMP is not a RESTful architecture.   There are some similarities if you look at very specific subsets of SNMP, but one can't use SNMP to build a hypermedia system.    

Now, certainly, WS-Man has adopted some specifications that initially were attempting to adopt some of REST's properties, but no one in practice is really using the technology as a RESTful architecture, since it only partially fulfills the constraints.    William Vambenepe, a WS standards co-author in that area, has a good recent summary on the current state of affairs:

http://stage.vambenepe.com/archives/225

Basically, there's a lot of politics involved with WS-Man.  

SaaS to really become mainstream needs (a) to separate the management interface from the service interface, and (b) use a widely accepted and simple to implement & use protocol such as WS-Man for that management interface. 

I wouldn't call WS-Man "easy to use" ;-).    

It is well supported in some cases, of course, and with tooling it can be made palatable, though I think it lacks many desirable properties.

Are there any SaaS applications out there that already do this?  I've yet to find any but this space is growing rapidly.

We're looking to do this, to some degree, with EDML at Elastra, though we're some time away from opening it up, and we don't really intend for it to be a standard -- just an open specification and some associated tooling.

Cheers

Stu

[Ian]

I like the 451 definition of a cloud environment (although there are lots of others out there): http://blog.skytap.com/2008/07/451-report-on-cloud-computing/

 

I don’t believe Rackspace offers the following characteristics on their VMware-based hosting services (but tell me if I’m wrong!):

 

- Enforce the discipline of a retail model

- An API. If there is no API, then it is not a service

- Virtualizes resources (e.g., CPU, storage) as a service  - multi-tenancy is key

- Self-service

- Enables resources to be consolidated

- Flexible

- Available on-demand

- Self-healing

- SLA-driven

 

-Ian

 

From: cloud-c...@googlegroups.com [mailto:cloud-c...@googlegroups.com] On Behalf Of Khazret Sapenov
Sent: Tuesday, July 29, 2008 7:25 PM
To: cloud-c...@googlegroups.com
Subject: Re: VMware steps into the cloud

 

 

On Tue, Jul 29, 2008 at 8:53 PM, Dave Kramer <ht_k...@hotmail.com> wrote:

[C Wegrzyn]

According to the 451 definition of "Cloud" Amazon's service isn't a
cloud. It isn't self-healing.

Chuck Wegrzyn

Ian wrote:
>
> I like the 451 definition of a cloud environment (although there are
> lots of others out there):
> http://blog.skytap.com/2008/07/451-report-on-cloud-computing/
>
> I don’t believe Rackspace offers the following characteristics on
> their VMware-based hosting services (but tell me if I’m wrong!):
>
> - Enforce the discipline of a retail model
>
> - An API. If there is no API, then it is not a service
>
> - Virtualizes resources (e.g., CPU, storage) as a service -
> multi-tenancy is key
>
> - Self-service
>
> - Enables resources to be consolidated
>
> - Flexible
>
> - Available on-demand
>
> - Self-healing
>
> - SLA-driven
>
> -Ian
>

> *From:* cloud-c...@googlegroups.com
> [mailto:cloud-c...@googlegroups.com] *On Behalf Of *Khazret Sapenov
> *Sent:* Tuesday, July 29, 2008 7:25 PM
> *To:* cloud-c...@googlegroups.com
> *Subject:* Re: VMware steps into the cloud

>
> On Tue, Jul 29, 2008 at 8:53 PM, Dave Kramer <ht_k...@hotmail.com
> <mailto:ht_k...@hotmail.com>> wrote:
>
> Rackspace has VMWare support ....Don't look at mosso .... Look at
> Rackspace hosting services ....
>
> "HT"
>
> Dave "HT" Kramer

> ht_k...@hotmail.com <mailto:ht_k...@hotmail.com>

> 972.636.5445
>
> How quickly all changes :)
>
> quote:
>
> "Hosting providers offering virtual servers could be barking up the

> wrong tree, according to Rackspace. *Virtualisation is not yet ready
> for the big time, and is unlikely to save its users money*, the

[Moshref]

Following is from Computer World:

 

Performance - you want the virtualized performance to be approximately equal to what the user is accustomed to. I have talked to a few people who found VMware virtual desktops to be unacceptably slow in their environment, while others have said it's ok. The point is that bandwidth, processor performance, and even the application demands on I/O processing can impact the choice of solutions. The first order of business is to make sure the virtual system performs for your end users. If it doesn't give an acceptable user experience, nothing else will matter.

 

Rgds,

Moshref

 

From: cloud-c...@googlegroups.com [mailto:cloud-c...@googlegroups.com] On Behalf Of Ian

Sent: Wednesday, July 30, 2008 9:06 AM
To: cloud-c...@googlegroups.com

[Paul Renaud]

Many folk do believe SNMP to be a Restful architecture.  For those that do, then WS-Man must be too.  For those that don't, it's certainly easier to see Restful principles at work within WS-Transfer and pretty much all of WS-Addressing.  In fact those two protocols (plus SSL) is all you need to use a subset of WS-Man to implement most of the equivalent functionality of SNMP.

 

WS-Man is considerably easier to use when compared to other management protocols (including SNMP).  Compared to other protocols, who cares?  The issue is manageability. 

 

Most importantly, to implement the basic and most common management function of polling the value of an attribute on a managed object - WS-Man is amazingly easy to use.  I can easily get a high school student, using nothing more than a text editor, an XML schema, and some basic instruction on how to read XML, up and coding valid queries in an afternoon.  That is simply not possible with SNMP's BER encoding, MIB tables, etc.

 

Yet SNMP is the dominant management protocol on the planet.  Unfortunately, SNMP's lack of security and lack of XML binding is impractical to use for managing SaaS and more generally cloud services.  The SaaS/Cloud industry needs its own SNMP-equivalent.

 

No one buys an unmanageable router, so why would we expect customers to buy unmanageable SaaS services?

 

Please do not inflict your proprietary management protocol on us by open sourcing it. Keep it to yourself as I'm sure it does what you need it to.  As for your consumers' needs there is no added value in introducing competing open implementations to something that already works, already provides the mechanisms required for managing the cloud, and is already widely accepted. 

 

SNMP became the dominant management protocol of the previous millennium because it was SIMPLE -- not based whether it was RESTful or not.  It's simplicity is what motivated thousands of smart people to stop trying to compete with it (it's easy to imagine extensions or improvements on it) and to realize their true objective of driving mass adoption of their product by promoting a common standard. 

 

A rising tide really does float all boats (that choose to throw away their proprietary anchors).

 

Yes there is some unnecessary fluff in WS-MAN (such as mechanisms to limiting the amount of info transferred), so there is added-value in defining a strict subset profile of WS-Man that can be used to simplify the majority of management implementations and promote adoption.   If anyone would like to work with me on this, please email me directly.

---

From: cloud-c...@googlegroups.com [mailto:cloud-c...@googlegroups.com] On Behalf Of Stuart Charlton
Sent: July 30, 2008 4:01 AM
To: cloud-c...@googlegroups.com
Subject: Re: WS-Man (was RE: VMware steps into the cloud)

[Igor Edelman]

(Disclosure: We are a VMware shop)   I can second Ormond's statement. I work for a large financial institution focusing on virtualization and "associated" technologies. One point of clarification is that a) implementation of moving one VM from one host to another differs from vendor to vendor. b) restrictions to the function exist, such as processor family etc.   Another point is that a Virtual Desktop Infrastructure (VDI) consists of a few more components than a "simple" server virtualization environment. I noticed a mentioning/discussion around VDI and thought it might help to point that out. Performance might be impacted by the implementation of a connection broker.   Vmotion could have started as a gimmick for sales - although very speculative statement in nature. The bottom line is that additional functions such as distributing resources fairly without impacting VMs, or in case of VMware 3.5 to develop the function of moving not only the VM but also it's associated data from LUN to LUN, were driven by Vmotion. Just to mention a few.   Igor   --- On Tue, 7/29/08, William Newport <bnew...@mac.com> wrote:

From: William Newport <bnew...@mac.com> Subject: Re: VMware steps into the cloud

[Sassa NF]

Why did you bring up BER as a drawback? It is only _encoding_, not the
schema. You aren't seriously suggesting that the enterprise users will
type raw XML for management just like your highschool student does!

Unless of course hiring that student works out cheaper than writing a
management GUI? ;-)

Sassa

2008/7/31 Paul Renaud <ren...@lanigangroup.ca>:

[Sassa NF]

Is that for a fact? Where can I read about that?

I'd expect the paravirtualisation to happen that way, i.e. expose the
devices via standard API, but I didn't think "the real" virtualisation
worked like that; I thought they'd use protected mode and handle
exceptions when "guest OS" wants to access I/O or execute a privileged
instruction. ...so there'd be no "API" that the guest OS could use:
the guest OS can use the API only when it knows it is
(para)virtualised.

Sassa

2008/7/29 William Newport <bnew...@mac.com>:

[Alexis Richardson]

Paul

On Thu, Jul 31, 2008 at 1:45 AM, Paul Renaud <ren...@lanigangroup.ca> wrote:
> Many folk do believe SNMP to be a Restful architecture. For those that do,
> then WS-Man must be too.

I think Stu's point was that CRUD is different from REST
(http://www.infoq.com/articles/rest-introduction) ... and that with
SNMP you don't get the "HATEOAS" property
(http://www.stucharlton.com/blog/archives/000141.html).

> SNMP became the dominant management protocol of the previous millennium
> because it was SIMPLE -- not based whether it was RESTful or not.

YES!

> Yes there is some unnecessary fluff in WS-MAN (such as mechanisms to
> limiting the amount of info transferred), so there is added-value in
> defining a strict subset profile of WS-Man that can be used to simplify the
> majority of management implementations and promote adoption.

I am sure we would all like to see this in action - can you describe
the subset of WS-Man that you have in mind please and explain for us
non experts (1) how this relates to SNMP, and (2) where, if ever, it
is important that a RESTful principle is used.

That would be great :-)

alexis

[William Newport]

Thats a fact
They are intercepting but they need to emulate registers on the actual
virtual hardware for the normal drivers in the operating system to
work. The virtual device that they are emulating is like an API to
talk with the actual network card on the server. Storage controllers
are everything else work the same way. Thus, the virtual machine image
is dependant on the spec of the virtual machine because when the
operating system was installed and 'detected' the hardware to select
drivers it is then bound to that specification and becomes, unportable.

Billy Newport
IBM eXtreme Scale | http://www-306.ibm.com/software/webservers/appserv/extremescale/

[Sam Johnston]

On Thu, Jul 31, 2008 at 8:23 AM, Sassa NF <sassa.nf@gmail.com> wrote:

Why did you bring up BER as a drawback? It is only _encoding_, not the
schema. You aren't seriously suggesting that the enterprise users will
type raw XML for management just like your highschool student does!

Actually, yes. While I have worked with people who could probably interrogate a router over SNMP by feeding netcat manually crafted ASN.1 requests, us mere mortals are less masochistic and tend to prefer stuff that 'just works'. These days, if I can't manipulate an API with cURL (or at least a line or two of perl, python or php and a common library) then it essentially doesn't exist.

As an example, why would I want to do a bunch of SOAP stuff to authenticate, subscribe, etc. to a log when that same logfile could be simply mapped to a URL (something akin to '$ tail -f /var/log/system.log |nc -l 3333', only with HTTP and/or SSL auth).
 

Unless of course hiring that student works out cheaper than writing a
management GUI? ;-)

How do you think [the most useful] GUIs get written in the first place?

Yes management is a complex problem and I realise there needs to be standards and infrastructure; I'm just playing devil's advocate.

Sam
 
--
Sam Johnston
Australian Online Solutions
http://www.aos.net.au/

[Ormond Merino]

To your point Igor - A standardized virtual machine definition will have to take vendor proprietary functionality into consideration. Citrix and Microsoft have already made statements that certain workloads will perform better on their hypervisor than on a competitor's. How would this impact a standard virtual machine definition?

 OVF is a good start, but in my opinion the standard should also take the following into consideration:

• HAL being presented to the guest. Each vendor presents a different x86 chipset to the guest, with certain limitations on number of PCI devices, etc.
• CPU family and stepping, including the ability to mask most instruction sets. Imagine if a guest has detected a certain instruction set on boot, then attempts to leverage that instruction set after it's migrated to a host that does not present it.
• Each vendor supplies a proprietary set of 'enhancements', which is a collection of tools, drivers, etc. that gets installed in a guest. These 'enhancements' provide the drivers for the devices presented by the HAL and work together with the virtualization layer to leverage the advanced features each vendor supplies.

On the subject of VDI, it is merely server based computing, and you should apply the same performance tuning, latency impact testing, and capacity planning as you would with any SBC platform (ie: Citrix, Terminal Servvices, etc.).Computer World is just stating the obvious in that respect.



...ormond

[Stuart Charlton]

On 30-Jul-08, at 5:45 PM, Paul Renaud wrote:

Many folk do believe SNMP to be a Restful architecture.  For those that do, then WS-Man must be too.  For those that don't, it's certainly easier to see Restful principles at work within WS-Transfer and pretty much all of WS-Addressing.  In fact those two protocols (plus SSL) is all you need to use a subset of WS-Man to implement most of the equivalent functionality of SNMP.

 

Sorry, those many folk that believe SNMP is RESTful are wrong.   I don't mean to be so blunt, but in this case, I can't say it any other way.    You can't just "will" something to be something when it's not, that path leads to nonsense.   

Most importantly, to implement the basic and most common management function of polling the value of an attribute on a managed object - WS-Man is amazingly easy to use.  I can easily get a high school student, using nothing more than a text editor, an XML schema, and some basic instruction on how to read XML, up and coding valid queries in an afternoon.  That is simply not possible with SNMP's BER encoding, MIB tables, etc.

That's utterly ludicrous.

Let me clarify: you're suggesting that a high school student is going to interact with a protocol, in an afternoon,  that incorporates over 5 to 6 different WS or XML related specs (Eventing, Enumeration, Transfer, Addressing, SOAP, XML Namespaces, and XML Schemas), with only a programming language,  an XML parser and HTTP library?  Not even a SOAP toolkit?

Adults with decades of experience have trouble with half of those specifications on their better days.  

  IBM had been claiming for quite a while that you can't actually implement WS-Man on even a *toolkit* like JAX-WS.  They're hardly high school students.    (Though, Sun has shown us it's quite possible with Project Wiseman.)

I think it's very easy to demonstrate polling a management value with an SNMP toolkit like SNMP4J, and reasonable on something like Wiseman.    You might even get a college graduate  to do it in a day.   

Though I'd also note that a high school student probably could build a script to poll a management variable over cURL in less than 30 minutes.

 

Please do not inflict your proprietary management protocol on us by open sourcing it. Keep it to yourself as I'm sure it does what you need it to.  As for your consumers' needs there is no added value in introducing competing open implementations to something that already works, already provides the mechanisms required for managing the cloud, and is already widely accepted. 

If you'd like to understand EDML and ECML better, there's a white paper on our website.   We're primarily focused on languages describing, storing, and collaborating on architectural designs, configurations, and pools of resources.   Neither WS-Man nor SNMP fulfill such requirements, and we will use them where they're appropriate.

 

SNMP became the dominant management protocol of the previous millennium because it was SIMPLE -- not based whether it was RESTful or not.  It's simplicity is what motivated thousands of smart people to stop trying to compete with it (it's easy to imagine extensions or improvements on it) and to realize their true objective of driving mass adoption of their product by promoting a common standard. 

Sure, I agree.   At the same time, the cloud is ripe for innovation in several areas.   

For example, would you suggest that Google expose their GData as WS-Man endpoints?  

How about Microsoft Astoria? 

These are all areas of overlap with WS-Man, but even vendors that supported and *defined* WS-Man, like Microsoft, are taking alternative approaches when dealing with the cloud.  You may want to consider why.

Cheers

Stu

[Randy Bias]

At the risk of being controversial, XML, SOAP, *and* SNMP are all
terrible solutions.

Having seen a lot of real world solutions I can tell you that your
average Ops person has no desire to read or write XML. SOAP, in this
regard, is just another nasty layer on top of it. Tooling only goes
so far to resolve this issue. In many real world situations, the
dominant monitoring and management tools aren't SNMP-based either.
Take Nagios for example. It's a widely deployed open source tool with
a large number of native plugins, most of which do not use SNMP. As
far as I can tell, SNMP has significant traction only in terms of
network management and monitoring. In terms of systems? Not so
much. Perhaps in commercial land, but no in open source land.

We need new data packaging standards that are user-friendly (JSON or
YAML anyone?) and I, for one, think the centralized monitoring
paradigm is fundamentally broken. If the machine is up and
operational it should monitor itself and the app that runs on it. It
should regularly report back it's status and that of the app. If it's
down, someone should be fixing it. Nothing else scales and nothing
else is as cloud friendly. It's really a distributed computing
problem at the end of the day.

--Randy

Randy Bias, Founder, CloudScale
(877) 636-8589, ran...@cloudscale.net
blog: http://neotactics.com/blog

[William Newport]

Agreed
I have long given up on ws-* as a simple solution for anything. Print
out the specs and stand them up on end. It's just scary. I don't think
anybody with a day job understands all those specs with any level of
detail. It's a mess.

I'd like to see simple standards like RSS/ATOM/JSON being used to
export metrics etc from entities. This is consumable by anybody with a
browser. I'm always thinking of exposing metrics from IBM eXtreme
Scale as an RSS feed with the last 30 values for example. This would
allow someone to use a company portal to build a management console
and view the news from CNN or indeed this mailing list along side it.
Software like yahoo pipes could be used to mine/build derivative
values from it and all without me having to do anything more complex
than export an RSS feed which is childs play to do.

Billy

Billy Newport

[Ray Nugent]

At the network layer SNMP rules by virtue of it's ubiquity, nothing more. And despite the fact that ASN.1 and MIB development continues to be the domain of high priests no one seems interested in changing it. (I have a good deal of experience with this problem.:-)  And so it will endure until Cisco falls some time next millennium. At all layers above the network layer, SNMP is neither ubiquitous nor appropriate. And so there is an opportunity...

Ray

----- Original Message ----
From: Randy Bias <ran...@cloudscale.net>
To: cloud-c...@googlegroups.com
Sent: Thursday, July 31, 2008 7:06:04 PM
Subject: Re: WS-Man (was RE: VMware steps into the cloud)

[Paul Renaud]

><snip>

>can you describe the subset of WS-Man that you have in mind please
>and explain for us non experts (1) how this relates to SNMP, and (2) where,
if ever, it is important that a RESTful
>principle is used.
>
>That would be great :-)
>alexis

Hi Alexis,

I apologize for this long response, but much of the confusion around cloud
protocol design flows from an inadequate separation of concerns about what
the protocol should be designed to do in the first place. The first such
separation is between the service itself and the management of that service.

Every network service has a service interface that has one or more primary
interfaces that it provides to its consumers on the network. This
interface(s) can and should be very specific to the service that is being
offered. A wide variety of design patterns for network interface design
(such as RESTful) may be useful in defining that interface. But no matter
how well that service interface is designed, something more is required.

Every network service should also have a separate and secure management
interface that is used to manage that service. This interface should NOT be
confused with the service interface (for example it must be available even
when the service is not - e.g. so that maintenance on the service can be
performed remotely).

Unlike the service interface which is best designed to meet the needs of the
service provided, the management interface must be designed to meet the
needs of the remote management application(s) that use it. These management
applications vary greatly and may be autonomic or have users at the steering
wheel; may be old-fashioned single hierarchy manager/agent style managers or
multi-hierarchy or peer-manager style; federated or isolated, etc.

Regardless of how the management side of the application is organized or
controlled, the accepted design pattern for the management interface is:

1. a simple schema describing the resources available for management (e.g.
MIB in SNMP, WS-Addressing compatible XML schema in WS-Man). This maps well
to the "give resources an ID" concept in REST.

2. a mandatory implementation of a synchronous polling mechanism (e.g. GET
in SNMP and anonymous mode WS-Transfer in WS-Man) that enables the retrieval
of the attributes of a single resource within that schema. This also maps
well into the REST pattern of getting the attributes of a URI. The
implementation that responds to the poll may or may not be stateless.

3. optional implementation of an asynchronous eventing mechanism (e.g. Trap
in SNMP and WS-Eventing sink in WS-Man) based on a simple subscription about
the status change on a resource. A subscription is necessary so that a
destination can be supplied for these events. Asynchronous eventing is
optional because although the same management purpose can be accomplished
with synchronous polling, it is far less stress on the network to use
eventing. Asynchronous eventing is non-RESTful.

4. the interface itself must be secure (SNMP has less than ideal community
strings and in v3 user/name password, while WS-Man uses certs). Security is
not prescribed by the REST pattern.

5. optional implementation of lifecycle management for the managed resource
(create, update, delete) subject to the authorization control provided by
the security of the management interface (e.g. SET in SNMP,
Create/Put/Delete in WS-Man). Some folk incorrectly argue that lifecycle
management via CRUD-like operations is non-RESTful but HTTP GET, POST, & PUT
are clearly CRUD-style verbs! (see
http://en.wikipedia.org/wiki/Representational_State_Transfer)

Since most management protocols also use a minimalistic set of commands to
implement the above, and operate in a client/server context, a case can be
made for arguing that they are Restful.

It really doesn't matter whether a management protocol is Restful or not -
the most important thing is that it is both simple & standard so that it
will be widely implemented by both service providers and a wide variety of
management applications. Simplicity gets lost when people confuse the
separation between the service itself and management of the service.

The separation between service and management interfaces has been a
fundamental principle of network systems design since the birth of network
computing. It is fundamental to the object-managed object paradigm and also
shows up in many other places too. A couple of examples of this separation
of concern are ICMP at the network layer and SNMP at the application layer.
For example, in the Internet all network elements implement IP (service
interface) and ICMP (management interface) at the inter-network layer.
Specific network elements such as routers implement a variety of routing
protocols such as EGP, etc.(service interface) and SNMP (management
interface).

This fundamental principle is also well known in non-data networks such as
the public telephone, radio, and TV broadcast networks etc. For example,
the vertical blanking interval in a television network is used to carry
signal synchronization (management interface) that is not displayed as part
of the video scanning stream (service interface).

The separation between service and management exists at the network
application layer too. For example, your website is a network application
that responds to HTTP requests (service interface), but standing up a new
website is not usually performed by that same interface. To create a new
website you would define a management interface with different semantics to
register your website and to PUT the new webpages onto your website. If you
were cunning you might even use HTTP as the transport mechanism for such an
interface. Just because the interfaces are different doesn't mean that the
protocol cannot be shared, but caution must be used when defining a
management protocol based on re-using other protocols.

The need to separate the different concerns between service & management
interface is something that the current band of WS-* protocol experts seem
to have forgotten (hence the protocol bloat within the WS-Man suite). It
pains me to see the W3C committees debating the merits of reliable
messaging, fancy soap optimizations, session-semantics, etc for use in
management protocols. Protocol bloat is what killed off the entire ISO suite
of protocols, including CMIP/CMISE for management.

Defining a strict subset within WS-Man would greatly simplify the situation,
promote adoption, and not break existing implementations.

A first cut at a minimalist subset of WS-Man would be:

1. WS-Transfer with only anonymous Reply-To in response/actions (maps to GET
and PUT in SNMP),
2. WS-Enumerate (maps to GET Next and GET Bulk in SNMP) without filtering,
without expiry, without max time or length, and without Get Status.
3. WS-Addressing as is.
4. Optional WS-Eventing (maps to SNMP Trap) without Subscription End (not
reliable anyway)
5. WS-Security with only X509 signed tokens (possibly with only a single
encryption method)

Cheers,
Paul

[Paul Renaud]

SNMP became ubiquitous because it was simple to implement and the networking world decided that it was more important to have a simple standard than it was to argue about how to make it perfect.  It was never intended for human readability.  However, SNMP isn't really feasible for most SaaS applications since it isn't "firewall friendly".

 

Our opportunity is to follow the example of what made SNMP so successful and rapidly adopt a common, existing, standard for SaaS management.  It doesn't have to be Restful, or perfect.  Like SNMP, it simply needs to be practical.

 

WS-Man fits the bill as a "next-gen SNMP" - particularly if we all use a strict subset to speed adoption.

---

From: cloud-c...@googlegroups.com [mailto:cloud-c...@googlegroups.com] On Behalf Of Ray Nugent
Sent: July 31, 2008 11:44 PM
To: cloud-c...@googlegroups.com

Subject: Re: WS-Man (was RE: VMware steps into the cloud)

[Sassa NF]

Hmmmm.... I was under impression that the hardware API is a set of
ports and interrupts, and is defined by hardware. VMWare's job is to
emulate the hardware, but they cannot introduce new device API, nor
can this API be VMWare-specific, under the assumption that the OS
drivers do not know the devices are virtualised. The drivers will
attempt to use the same hardware ports, and neither the ports they
use, nor the expected behaviour depends on VMWare. All VMWare can do,
is introduce new bugs (e.g. time goes back).

I think it is as much a lock-in, as the OS software would be locked-in
after installing it on a physical machine.

However, in a paravirtualised environment this does happen
differently, but then the device drivers are
(para)virtualisation-aware (virtualisation-specific); in fact, it
seems it is the device drivers through which para-virtualisation is
achieved.

That's my understanding of virtualisation.

Sassa

2008/7/31 William Newport <bnew...@mac.com>:

[Sassa NF]

2008/7/31 Sam Johnston <sa...@samj.net>:

> On Thu, Jul 31, 2008 at 8:23 AM, Sassa NF <sass...@gmail.com> wrote:
>>
>> Why did you bring up BER as a drawback? It is only _encoding_, not the
>> schema. You aren't seriously suggesting that the enterprise users will
>> type raw XML for management just like your highschool student does!
>
> Actually, yes. While I have worked with people who could probably
> interrogate a router over SNMP by feeding netcat manually crafted ASN.1
> requests, us mere mortals are less masochistic and tend to prefer stuff that
> 'just works'. These days, if I can't manipulate an API with cURL (or at
> least a line or two of perl, python or php and a common library) then it
> essentially doesn't exist.

:-) Yes, the XML has advantage only in adoption of the technology by
the developers, as they can play with it without having to bother with
the encoding. If there were ubiquitous libraries for handcrafting BER
out of a declarative text, like ASN.1 definitions with the values
filled in, there wouldn't be any difference. On the other hand, such
libraries would have existed only if BER was adopted by the developers
;-)

Oh, and here's a NSNMP Perl library for you:
http://search.cpan.org/~kragen/NSNMP-0.5/NSNMP.pm

> As an example, why would I want to do a bunch of SOAP stuff to authenticate,
> subscribe, etc. to a log when that same logfile could be simply mapped to a
> URL (something akin to '$ tail -f /var/log/system.log |nc -l 3333', only
> with HTTP and/or SSL auth).
>
>> Unless of course hiring that student works out cheaper than writing a
>> management GUI? ;-)
>
> How do you think [the most useful] GUIs get written in the first place?

Certainly, *not* by handcrafting the XML!

(I don't regard copy-pasting the examples as *handcrafting*, because
in that case you could as well handcraft any BER from the examples.
Without copy-pasting any solution is prone to typos, especially in
long and unreadable URIs (or OIDs for that matter))

Sassa

[Sassa NF]

Centralised monitoring is needed for centralised management. Learn to
scale management, then we can scale monitoring as well. As for sending
a "digest" of metrics instead of raw metrics, this reduces the problem
N times, N=number of metrics, not M times, M=number of monitored
entities.

Sassa

2008/8/1 Randy Bias <ran...@cloudscale.net>:

[Sassa NF]

2008/8/1 Paul Renaud <ren...@lanigangroup.ca>:
...

> A first cut at a minimalist subset of WS-Man would be:
>
> 1. WS-Transfer with only anonymous Reply-To in response/actions (maps to GET
> and PUT in SNMP),
> 2. WS-Enumerate (maps to GET Next and GET Bulk in SNMP) without filtering,
> without expiry, without max time or length, and without Get Status.
> 3. WS-Addressing as is.
> 4. Optional WS-Eventing (maps to SNMP Trap) without Subscription End (not
> reliable anyway)
> 5. WS-Security with only X509 signed tokens (possibly with only a single
> encryption method)

6. Disaster-proof features: can't rely on distributed systems, because
this interface is for managing them, including lifecycle management

X.509 scales authentication, but this has nothing to do with
authorisation. Try to devise a scalable access control policy and
access control management infrastructure (PMI). Is X.509 PMI part of
WS-Security? And what do you do if the Root CA PKC / PKC repository /
AC repository is not available (the interface should be
disaster-proof)? You fall back to simple unscalable forms of
authentication and authorisation (hence the simplicity of these in
SNMP).

Oh, and both X.509 PKI and X.509 PMI are based on BER-encoded tokens.
Anyone up to handcraft that in XML? ;-)

Sassa

> Cheers,
> Paul

[Sassa NF]

RSS for monitoring? Maybe. But Management is more than monitoring.

Sassa

2008/8/1 William Newport <bnew...@mac.com>:

[Barr, Bill]

Have you shared your sentiments with your colleagues (culprits) who are
key contributors to the WS* mess?

-----Original Message-----
From: cloud-c...@googlegroups.com
[mailto:cloud-c...@googlegroups.com] On Behalf Of William Newport
Sent: Thursday, July 31, 2008 7:37 PM
To: cloud-c...@googlegroups.com
Subject: Re: WS-Man (was RE: VMware steps into the cloud)

[William Newport]

I'm not known for being shy...

Are we going to send a million management events per second encoded as
XML within SOAP packets, I don't think so. Network bandwidth is an
issue (especially when you're paying per bit in a cloud...).

While IBM is clearly committed to ws-*, it's not something I work on
directly or worry about at all.

Billy Newport

[Ray Nugent]

SNMP became ubiquitous because of it's low overhead and thus small impact on the network. Remember that when Marshall Rose created it "broadband" was a 64K line...

I'm not sure WS-M would be considered either simple or low overhead. Lots of XML based management systems have failed to overtake SNMP. We'll see how WS-M does.

----- Original Message ----
From: Paul Renaud <ren...@lanigangroup.ca>
To: cloud-c...@googlegroups.com
Sent: Thursday, July 31, 2008 11:26:09 PM
Subject: RE: WS-Man (was RE: VMware steps into the cloud)

SNMP became ubiquitous because it was simple to implement and the networking world decided that it was more important to have a simple standard than it was to argue about how to make it perfect.  It was never intended for human readability.  However, SNMP isn't really feasible for most SaaS applications since it isn't "firewall friendly".

 

Our opportunity is to follow the example of what made SNMP so successful and rapidly adopt a common, existing, standard for SaaS management.  It doesn't have to be Restful, or perfect.  Like SNMP, it simply needs to be practical.

 

WS-Man fits the bill as a "next-gen SNMP" - particularly if we all use a strict subset to speed adoption.

From: cloud-c...@googlegroups.com [mailto:cloud-c...@googlegroups.com] On Behalf Of Ray Nugent

Sent: July 31, 2008 11:44 PM

To: cloud-c...@googlegroups.com
Subject: Re: WS-Man (was RE: VMware steps into the cloud)

[Kristi Schultz]

Paul Renaud wrote on 08/01/2008 01:16:36 AM:

Paul, as I read your post, I expected you to recommend RESTful interfaces,
period. Not sure I followed why you thought WS-Man is necessary?

BTW - on event notifications, using RSS/ATOM is a perfectly acceptable
RESTful way of doing that.

[Dan Kearns]

On Fri, Aug 1, 2008 at 9:12 AM, William Newport <bnew...@mac.com> wrote:

I'm not known for being shy...

Are we going to send a million management events per second encoded as
XML within SOAP packets, I don't think so. Network bandwidth is an
issue (especially when you're paying per bit in a cloud...).

I won't be defending ws-* either, but for argument's sake, let's completely discount the development and integration costs as irrelevant.

A million events per second sounds like a lot of stuff to be failing all at once under the domain of a single responsible entity.

It isn't clear to me how the potential ~10-100x cost benefit from custom encodings and protocols vs soap+xml makes enough of a difference at that scale to justify the continued existence of an architecture which requires it.

-d

[William Newport]

I think CPU cost to generate and consume the events is one factor for the ASN and compiled versions and the cost per network bit charging model.

If you want to consume events using RSS/ATOM though, XML or a text property like encoding, JSON are the only real options. So, I'm on the fence, I can see both sides as far as network efficient and readable. It's hard to beat pulling metrics using RSS and a browser versus almost anything else in terms of footprint. Maybe different 'feeds' with different encodings.

Billy

[Sassa NF]

Let's put this straight. CPU savings come from definite length
encoding. Network bandwidth savings come from using more efficient
packaging of the bits.

So, XML is as good on the bandwidth side as BER, if you are sending
mostly text. The BER can save you CPU on the decoding side, as it has
a definite-length form. There probably is no difference on the
encoding side for simple text structures.

So by using BER to consume text messages, you will save a few CPU
cycles on the client end, where they are quite cheap anyway. If you
were to save the bandwidth, you'd probably need to have a Base*46*
encoding.

Sassa

2008/8/1 William Newport <bnew...@mac.com>:

[Krishna Sankar (ksankar)]

|ports and interrupts, and is defined by hardware. VMWare's job is to
|emulate the hardware, but they cannot introduce new device API, nor
|can this API be VMWare-specific, under the assumption that the OS

<KS>
Agreed, but ...

While VMWare cannot introduce southbound APIs, they can add
Northbound APIs; even some east-west i.e. between VMs for coordination,
state et al. IMHO, we have virtualization 2.0 ;o) While hardware
mediation and partition layer were the original virtualization
propositions - with consolidation and utilization as business value
propositions, the charter of the domain has evolved a lot since the
advent of "cloud computing". Mobility of VMs (static or dynamic), the
various aspects of HA, management, locality et al plus just plain old
resource balancing will necessitate a bigger role (and hence more
interfaces, programming models et al) for the lowly VM layer !

BTW, these will be based on interoperable open standards and not
based on lock-ins.
</KS>

Cheers
<k/>

|-----Original Message-----
|From: cloud-c...@googlegroups.com [mailto:cloud-

|comp...@googlegroups.com] On Behalf Of Sassa NF
|Sent: Friday, August 01, 2008 1:34 AM
|To: cloud-c...@googlegroups.com

|Subject: Re: VMware steps into the cloud
|
|

[Randy Bias]

On Aug 1, 2008, at 5:51 AM, Sassa NF wrote:
> Centralised monitoring is needed for centralised management. Learn to
> scale management, then we can scale monitoring as well. As for sending
> a "digest" of metrics instead of raw metrics, this reduces the problem
> N times, N=number of metrics, not M times, M=number of monitored
> entities.

You're confusing management with monitoring. Monitoring is the
instrumentation of systems, which is easily distributable. Management
is the ability to take action (including alerting or response) based
on monitoring data. Monitoring is inherently distributable, but most
historical solutions bind management and monitoring together too
tightly.

Decentralizing management isn't that hard. It's mostly about
federating and focusing on applications, not datacenters. Datacenters
are a paradigm that is soon to be extinct.

[Sassa NF]

Yep, I can see this role, too, but if the guest OS is unaware of
virtualisation, there is no lock-in, is there?

(alright, subject to portability of the OS image that does not require
a "cold-reboot" of the image)

Sassa

2008/8/1 Krishna Sankar (ksankar) <ksa...@cisco.com>:

[Sassa NF]

I don't think I am confusing them :-) They started talking of
management, and later monitoring, because management without
monitoring won't work. Also, monitoring without management is a little
pointless, unless you want your boss to see the nice dials with the
metrics (for any particular reason).

I agree monitoring is scalable, but scaling that is not needed without
scaling management. Wouldn't it be like having a scalable "feed"
without a scalable "feed back"?

I think there are some management operations that don't scale. For
example, federation works, once it is there. But creating a federation
is not scalable, because you can only select the members one by one.
There will be many other bootstrapping functions that won't scale.

Sassa

2008/8/2 Randy Bias <ran...@cloudscale.net>: