Since its very first version, vRanger has allowed users to extend its functionality and integrate it with other applications in their environment through the use of scripting. Long ago, in the pre-VirtualCenter days, before we had the ability backup all of the virtual machines on an individual ESX host directly in the product using the -allregisteredvms switch we created a script using the vRanger command-line interface (CLI) to do this. We understood the importance of having a scriptable interface and we made sure to provide one for our users so that they could do the same sort of thing. As we were designing vRanger Pro 4.0 DPP we wanted to retain the spirit of our CLI and allow for new types of integration, so we created the web service interface that we call the vAPI.

The vAPI web service interface acts as a facade, exposing services in the vRanger Pro 4.0 DPP platform to the outside world. The main areas that these services cover are: inventory, repositories, connections, and jobs. Developers can choose to expose functionality in their clients as they see fit. For example, an application may choose to observe events relating to jobs and display notifications about their completion and result. Another could create backup and/or restore jobs in vRanger and run them. For the administrator, we’ve created special vAPI clients, the PowerShell cmdlets.

While the vAPI web service interface is developer focused, the PowerShell cmdlets are administrator focused. The set of cmdlets that we have created give the administrator open-ended access to the platform. By using these, we allow the administrator to integrate vRanger with third-party software and to create scripts automating the protection of their virtual infrastructure. The administrator’s abilities have been greatly enhanced compared to previous releases. We expose much more of our platform functionality than ever before, with 33 cmdlets covering the main functional areas of the vRanger platform. For those interested in trying our PowerShell support, here are a few basic cmdlets that can help you get started:

1. get-pssnapin - Lists all of the PowerShell snap-ins registered on the computer.  You should see one corresponding to vRanger in the resulting list if you are running the vRanger PowerShell console.
2. get-command - Lists all of the cmdlets available. If you wanted a list only those pertaining to vRanger, you could issue the command “get-command -pssnapin vranger.api.powershell” in the vRanger PowerShell console.
3. get-help - This cmdlet displays online help for PowerShell. For information about the Get-Repository cmdlet, you could issue the command “get-help Get-Repository” in the vRanger PowerShell console.

The vAPI web service allows for vRanger platform integration. It presents the core functionality of vRanger Pro 4.0 DPP to the outside world. Developers can consume the web service directly, and administrators can use the PowerShell cmdlets to create scripts to customize data protection in their environment.

–Dave

‘Sprawl’ is one of those overused terms in virtualization. Although to date, in my opinion, there is not a better description out there that can conjure up fear and groans in equal measure. Simply put, it is synonymous with ‘management overhead’!

Today I’m going to write about another kind of sprawl (like you really need another kind of sprawl!) - Virtualization Vendor Sprawl.

Over the years many niche players have arisen to fill in the technology gaps that were left open by mainstream virtualization. In most organizations the process of vendor consolidation is one that most growing or acquisitive enterprises will face from time to time. It’s not a task that is relished by those involved and it always proves to be a tightrope walk of cutting costs without cutting corners.

If you’ve already been through this exercise then there is not much I can add to your experience with this article. But I would ask that you share your experiences at the end of this article, for the benefit of our readership. For those about to take this route, I hope I can give you some useful points to consider.

First, what are the benefits of vendor consolidation? Vendor Consolidation has many advantages if it is done correctly, such as:

• Reduced number of contracts/documents
• Reduced number of contacts
• Easier negotiation/purchasing/procurement
• Better discount levels
• Reduced maintenance costs
• Renewals streamlined
• Service levels are consistent
• Support is consistent
• Product interaction/integration should be simplified

Sounds great doesn’t it? But before you throw out that entire extraneous product and give all your money to the largest gorilla in the room, here are a few things to consider:

• How do we get to that point?
• Are you trading-off against ‘best of breed’ technologies?
• Does vendor ‘lock-in’ give you the best deal all-round?

In addition to looking at the technologies that a company offers, in this day and age you  also need to look at their balance sheets and financial stability to make sure that they are capable of going the distance with you.

When collecting technologies together, some products may not fit neatly into categories in the same way their physical counterpart technologies did. For example, does virtualization backup fit with virtualization technologies or backup technologies, or neither? Does it fit with DR technologies?

Are you at risk of trading off ‘best of breed’ technologies? This is always the biggest concern; throwing the baby out with the bathwater so to speak. Despite virtualization being relatively new, it is mature enough to have multiple vendors with overlapping technologies. This means you should probably investigate how many candidate vendors can give you more. You probably won’t find a vendor that will deliver everything, but it makes sense to choose one that can deliver on a lot of things and is not focused on a single, specific aspect of virtualization.

This leads to the last point, vendor lock-in. If you bet the farm on one single vendor, then this can prove painful if not risky. It could affect your agility and ability to manage your virtualization investment. Just remember though, this process is designed for those who are in this for the long-haul. With that in mind the vendors you choose should be selected with that in mind and therefore start-ups will probably not figure in your list. The larger companies are capable of weathering the economic storms. But also, they can make the strategic acquisitions that ultimately will add value to your existing investment.

Vendors such as Oracle, Microsoft, VMware and Quest continually make acquisitions to help their customers “bridge the gap” by ensuring that best of breed is not lost by vendor consolidation.

Please feel free to share your experiences.

-Paul Martin

I’ve been hearing more about customers embracing ESXi, and even more that some are beginning to deploy it at scale in production environments. I want to share a few brief notes of concern that I have validated with other large customers and with some hardware manufacturers.

The VMware kernel part of ESXi seems to be rock solid, same as their other core hypervisor stuff.  So the concerns outlined below are not meant to say that VMware’s ESXi is not ready for primetime production use, but rather as suggestions to make sure it’s right for you.

Several customers, and two of the big three hardware vendors, are raising a flag and saying that customers should be aware of what hardware failure and performance alerts they can’t receive on ESXi hosts.  Customers can minimize the impact of these concerns with the following recommendations:

• Customers should perform extensive testing in their environment with ESX 3.5 beside ESXi and compare the alerts each generate from such failures as the removal of a power supply, drive, array controllers and memory errors.
• Customers should only run non-critical loads (dev/test/etc) in ESXi for a measured period of time to fully understand its performance and monitoring characteristics in their specific environment.
• Customers should establish a conversation with another customer that has been down the path of trying ESXi in their environment.  These peer-to-peer conversations really do add a lot of real world experiences to the conversation.
• Customers should take a close look at all of their infrastructure tools in the new environment: backups, replication, security, audit, monitoring, asset management, capacity planning, provisioning, etc.  Many might not function since their agents are longer able to exist in the console OS.  Others could be significantly impacted in performance due to alternate means of execution.

The bottom line is that I’m not suggesting that ESXi is not a great fit for customers in their environments, but rather that most customers experience some significant pain while they learn how to manage ESXi in their unique environment.  Vizioncore can be a trusted advisor by merely pointing out some of the pain points, such as those above that have been experienced by others; however we are not typically able to assist further than referring them to a partner to help with the VMware side of the execution with products other than our own.

I am very interested in your experiences around this topic and would welcome any corrections, or alternate views that you have.

Sincerely,

Brad Wagner
Director of Product Strategy
Vizioncore