virtualization.info

The Cultural Impacts

The last post covered cost models and changes needed to adopt virtualization, this post will cover the cultural change aspect of the technology within a company.

As typical with technology, change is constant but always a battle as many people do not embrace it.  Virtualization has been one of the biggest changes in technology in several years.  The reason is that virtualization touches so many different technology disciplines.  This one technology causes change in server, storage, network, data centers, software management, etc.  Therefore, virtualization is a very disruptive technology, but for good reason.

The challenge is managing this change across all these groups and keeping the technology and program moving forward.  The first a request is made to a network team to have 5 to 8 physical network connections to a few x86 servers but over 100 IP addresses, or a few terabytes of storage at one time for an environment consisting of multiple physical servers that all need to see the same storage - these are request that will get similar responses to the Internet replacing newspapers - it will never happen!  But, it will happen, although the change should be as non-disruptive as possible to keep program moving forward.

Communication is key in this space, this will be covered more in a later post.  Education of the support teams across the different disciplines is also very important.  The better they understand the technology and why they are being asked to make the changes the more receptive they will be. Another successful approach is to keep as many things the same as they are today, but tweak things to make them work in the virtual world.  In other words, make baby steps, the less disruptive the change is at a given point in time the less those effected will even realize things are changing.  The goal would be that they look back in a few months and say "Wow, did not even realize we had changed at this level".

In summary, do not build new policies and procedures from scratch were it can be avoided, try to retro fit the existing to get the virtualization program started and continue to review and tweak the processes and procedures as the program grows.  This will make the level of change appear less disruptive and will not not cause a rebellion from support teams against virtualization due to the level of change.

The next post will cover operational readiness for virtualization and what items need to be addressed before getting too deep into the program.

Cost Models and Chargeback's

Continuing from the last post covering data metrics, a solid cost model is needed to sell the program and saves from virtualization. The company needs to see a significant save to offset the investment and disruption from virtualization.

Most corporations have a cost model in place for technology, some purchase hardware and software centrally and charge the businesses via a rate card based model. Other models allow the businesses to purchase the hardware and software and charge centrally for shared services like network, email, etc.

Regardless of the model in place, virtualization cost for the company must show a save in order to sell the program. If the cost model in place does not show a signification save by moving from one physical server running one OS instance to one physical server running many OS instances, then there is an issue with the existing model that needs to be addressed. Fundamentally, virtualization should save money.

Almost every cost model will have pros and cons, a pure usage model can cause under recovery unless fully utilized while a dedicated model can cost more for the business in the initial ramp up period.

There are ways to incent virtualization through the cost model. Look at the long term advantages and saves of virtualization, not the short term cost. Concessions upfront can help open the door and not have initial cost be negative factor for moving to virtualization for the businesses.

As an example, a larger company that has multiple businesses and high volumes of virtual candidates may look at a model of building dedicated virtual farms or clusters by business sector. Using the existing cost model for physical environments, the business would pay the cost of all the infrastructure (servers, network, virtualization software, etc.) for a full environment. Actual charges can be applied at the Virtual instance level based on the total cost of the environment divided by the number of virtual instances (with some logical per instance calculations for the numbers of virtual CPU’s, RAM, storage, etc.). With a concession of no charges for the first 90 or 180 days of the life of the environment, the more the businesses virtualize in that time period, and beyond, the cheaper the per virtual instance cost.

Whichever cost model is used, it is imperative that the cost model incents the businesses and company to move to virtualization. If a virtual technology that has a perception of performance degradation, cost the same or more than physical servers it will be difficult to get buy in to move to the technology.

The next post will discuss Cultural Impacts, also known as “Change” that comes with implementing virtualization.

Meanwhile, please share your comments and feedback related to cost models for virtualization.

Update: The article below has been temporary removed after that some VMware distributors and the company itself have indicated how some statements are far from reality.
We removed the article to have time to further investigate and correct our mistakes, if any, without spreading false information.

We can confirm now that it’s not true that a VI 3 Standard license plus a-la-carte vMotion and Storage vMotion can’t be moved to a vSphere 4 Standard license while retaining those features.
VMware clarifies this with a footnote at this URL:

Customers with current Support & Subscription contracts who purchased VMware VMotion as an add-on to VMware Infrastructure 3 Foundation or VMware Infrastructure 3 Standard also received VMware Storage VMotion. These customers retain both VMware VMotion and VMware Storage VMotion when they receive VMware vSphere Standard.

But it’s also true that a number of customers were told by VMware sales representatives that their only upgrade choice was to move on the vSphere Enteprise Plus, as reported in the original article below.
We have full details about these customers, that asked to stay anonymous, and yes, they are outraged.

We sincerely apologize for not better checking with VMware before publishing this story.

Never like now VMware has hit a low level of popularity because of its pricing strategy.
The virtualization leader grew steadily in the enterprise market to the point that its products are now adopted in 100% of Fortune 100 and 95% of Fortune 500, but it has been considered out of range by most SMBs so far.
The new licensing upgrade scheme introduced with vSphere 4.0 is further compromising the already delicate relationship.

There are main two problems with that.

The first, pointed out in April, is that VMware has introduced a completely new top license called Enterprise Plus, which is not available as a free upgrade for the owners of the VI3 Enterprise license, and which is mandatory for those servers featuring more than 6 cores per socket.
This means that as soon as 8-cores CPUs become the standard, any enterprise buying new machines will be obliged to purchase an Enterprise Plus license and spend $600 more per socket.

The second problem is that VMware didn’t provide an upgrade paths for some key feature like vMotion and Storage vMotion when they are licensed a-la-carte.
Those customers that currently have a VI 3 Standard license and those additional capabilities, can’t keep them when migrating to the new vSphere 4 Standard license.
The “nearest” licensing level that includes vMotion and Storage vMotion is the new Enterprise, but VMware is not allowing its VI 3 Standard customers to move on that one.
The only allowed upgrade path in this scenario is from VI 3 Standard to vSphere 4 Enterprise Plus, which implies paying a huge, unplanned premium.

This last issue is critical because it touches those medium businesses that trust VMware and just want their vMotion.
It’s not that they don’t have alternatives now that Citrix and (very soon) Microsoft offer vMotion-like capabilities for free as part of their free hypervisors.
No matter how many features VMware is packing in vSphere or how mature is perceived its platform: the current company behavior is pushing the customers right in the arms of the competitors. And looking at some outraged feedbacks received by virtualization.info lately, those customers may be happy to go.

Labels: VMware

In the last two years pretty much every major vendor in the IT industry rushed to develop a rich VDI portfolio and roadmap. Each of them did its best to acquire promising startups, to announce new and highly efficient remote desktop protocols, to sign partnerships with OEMs for the next generation thin client.

From VMware to Citrix, from Sun to Quest, from HP to Verizon.
Even TV vendors like LG want to be part of the VDI game.
Everyone but Microsoft.

So far Microsoft preferred to stay under the radar as much as possible, even when they acquired Calista Technologies in January 2008, a small startup able to offload the remote client from the task of rendering any sort of multimedia resource; even when they announced some basic desktop brokering capabilities in the imminent Windows Server 2008 R2.

Now some concrete details are finally emerging and the Microsoft VDI strategy seems more interesting than expected:

…In the RTM version of Windows 7 and Windows Server 2008 R2, GDI applications, media with Windows Media Player, and Aero Glass will continue using the client-side rendering for remote scenarios as demonstrated in the pre-release version. For the RTM release, client-based rendering will no longer be available for DirectX 10.1 / DXGI 1.1 and Direct 2D applications, instead this type of content will be remoted using host-side resources leveraging the enhanced bitmap acceleration capabilities in R2. This decision was made based on the feedback we received during the engineering and validation process, where the number one requirement was quality and robustness.  While this design change may impact the utilization of CPU and GPU resources on the host side for certain use cases, it provides a consistent approach to remoting multiple types of rich (2D and 3D) content across a broad range of rich and thin client devices.

…

As for running DirectX applications on Windows Server 2008 R2 Hyper-V virtual machines, there will be the GPU offload hardware assist Calista technologies at some point in the future…

So basically Microsoft doesn’t just plan to integrate Calista technologies in RDP as already announced, but it also plans to elaborate on the virtualization host those multimedia contents executed inside the VDI virtual desktops (Brian Madden has additional insights about this).

The key point is that Microsoft knows a lot about the roadmap of the upcoming GPUs that many customers may be ignoring at the moment.
Those next generation display cards will be just another piece, along with a new remote desktop and a client hypervisor, of the very complex infrastructure that will have to build in the future to make VDI a really efficient solution.

Labels: Microsoft, VDI

Ten days ago Red Hat announced that its new, much awaited, virtualization offering based on KVM was in beta and that the beta program was oversubscribed.

The reality is that, as far as we know, Red Hat never announced the beta program or the details of its implementation of the Qumranet technology (acquired in September 2008), and never gave the opportunity to sign for it to the general public.
Still today there not a single bit of information about what Red Hat did in one year and a half after dropping Xen in favor of KVM.

Red Hat will take another two months to finally tell the world as LeMagIT revealed earlier today: the general availability of the new virtualization platform is in fact planned for September 1, 2009, which means during the VMware VMworld 2009.
Too bad that this year VMware is not particularly happy to have competitors showing their solutions on the exhibit floor.

Labels: KVM, Red Hat

As part of its renovation plan, in October 2008 PHD Virtual (formerly PHD Technologies) acquired the software division of a popular UK consulting firm, Xtravirt.
The company rebranded the Xtravirt tools and offered part of them for free in March, hoping to attract a large number of prospects that could be also interested in its flagship backup product called esXpress.

After a break to release a long overdue new version of esXpress, PHD is back on its plan to distribute for free the Xtravirt tools and launches Patch Downloader 6.0, a product that automates the download of VMware ESX patches in a file repository of choice.

There’s a number of similar tools and scripts out there and, like Patch Downloader, all of them are free.
One, called VMTS Patch Manager, was released by Massimiliano Daneri, of VMBK.pl fame, before he joined VMware.
Another one, called esxPatcher, was released by the German consulting firm Mightycare.

And of course there’s the VMware Update Manager (VUM) which is part of VI3.x and vSphere 4.0.
PHD Virtual says that their new tool is an alternative to VUM when the VMware customer doesn’t have a license to use it or can’t access the Internet from vCenter or the ESX hosts.

Labels: PHD Virtual Technologies, Releases

Yesterday in a public webinar VMware announced the upcoming release of Studio 2.0, the environment to author OVF packages that the company launched in September 2008.

The new VMware Studio 2.0 is remarkable in terms of new features.

The first most important is that it will support the new generation of virtual appliances (VAs) that VMware calls vApps.
The vApp is a concept that VMware introduced for the first time at VMworld 2008, and it implies a new metadata layer wrapping the virtual appliance what describes the virtual hardware, performance and security requirements to run the virtual machine.

Once created the virtual appliance or the vApp, Studio 2.0 will be able to deliver it on VMware Workstation, Server (both 1.x and 2.x) and of course VI/vSphere.
The most interesting thing about this last interaction is that Studio can push (and update at a later time) the new VA/vApp through VMware Update Manager (VUM).

Another two key features are the capability to author/build Windows virtual machines and the capability to use an existing virtual machine as input.

Studio 2.0 itself will be delivered as a virtual appliance, featuring Ubuntu Linux as the OS of choice.
Developers will be able to interact with it through a web browser, CLI or a plug-in for Eclipse.

Thanks to vinternals for the news.

Labels: Standards, VMware

With the first post in a new corporate blog, VMware unveiled the existence of Code Central, an online facility where its community can upload and exchange scripts for the various VMware SDKs.

VMware has a special interest in seeing what kind of automation the virtualization professionals want to have now that its vCenter Orchestrator has been released as a free module of vSphere 4.0.

Orchestrator is powered by the technology that VMware acquired by Dunes Technologies in September 2007.
The Dunes framework is powerful and flexible enough to become the foundation for new products, from a VDI connection broker to a virtual lab automation manager.
In most cases the customers will use it to automate specific aspects of their environments, but once in a while a Code Central public script become popular enough to give the input to VMware for a new, non-free product.

This is the same strategy that is being pursued by Vizioncore, which recently launched a free scripting IDE for PowerShell called Virtualization EcoShell, an extension of the PowerGUI console that its parent company Quest releases for free a long time ago.
Also in this case, Quest/Vizioncore is giving away the tools for free to grow a loyal developers community and see if any member can produce something amazing to extend their new automation product called vControl.

Labels: Platform Orchestration, VMware

While opening the beta program of the next Fusion major release, VMware also keeps updating the current product which now reaches version 2.0.5 (build 173382).

Fusion 2.0.5 is mainly for bug fixes but it also extends the support to the following host and guest operating systems:

• Host OSes
  Mac OS X 10.6 codename Snow Leopard (32bit only, experimental)
• Guest OSes
  Mac OS X 10.5 (on new Intel Xeon 5500 and 3500 Series)
  Ubuntu 9.04
  Mac OS X 10.6 Server codename Snow Leopard (32bit only experimental)

Labels: Releases, VMware

Citrix just release the first minor update for its P2V/V2V migration tool XenConvert 2.0.

This version introduces the support for OVF contents created with VMware vSphere 4, plus it enhances support for OVF and VMDK files created with other VMware products, including VI 3.x, Workstation 6.5.2, Studio 1.0, OVF Tool 0.9, Converter 3.0.3 and 4.0.

The product is free and available here.

Labels: Citrix, P2V/V2V Migration, Releases