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
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/
Â
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.
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
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
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 |
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
Reuven
I would be interested in hearing some real world experiences with Live
migration. Mine haven't been very good.
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
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.
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.
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:
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
(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 Â
|
From: William Newport <bnew...@mac.com> |
Unless of course hiring that student works out cheaper than writing a
management GUI? ;-)
Sassa
2008/7/31 Paul Renaud <ren...@lanigangroup.ca>:
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>:
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
Billy Newport
IBM eXtreme Scale | http://www-306.ibm.com/software/webservers/appserv/extremescale/
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? ;-)
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.Â
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.
Â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.Â
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
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
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
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>:
:-) 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
2008/8/1 Randy Bias <ran...@cloudscale.net>:
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
2008/8/1 William Newport <bnew...@mac.com>:
-----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)
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
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.
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...).
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>:
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.
(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>:
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>: