Virtualization strategies

How do your virtual machines compare with your peers’? Find out

A small virtual appliance company in Portsmouth, N.H. called vKernel first grabbed my attention last year with its virtualization management software, and they have it again with a new online virtualization community called Compare My VM.

The site gives users a way to annonymously compare their virtual machine (VM) configurations, by application category, with peers to see how others are allocating resources, and hopefully, take something useful back to your own environment.

vKernel’s Founder and CEO, Alex Bakman, came up with the CompareMyVM idea to help the IT community learn from each other about allocating resources for specific application VMs. 

“How to properly allocate resources in a virtual environment is still a trial and error process.  Simply using the same allocations of a physical server when virtualizing it can quickly lead to resource capacity issues caused by either over or under allocations,” said vKernel’s communications director, Christian Simko. “Ultimately, users can come to the site to learn how to ‘right size’ VMs so that they can drive higher VM densities without impacting performance.”

By setting Compare My VM up as a community site, visitors are more apt to share with and learn from their peers, than to have a product vendor tell users how and what to do, Simko explained.

So far, Compare My VM has around 300 submissions. Users typically enter their VM info either because they think their VM set up is da bomb, or because they need some help, which is why vKernel added a peer to peer ranking system on the site, Simko said. 

“One person may think their set up for an MS SQL VM supporting X number of users is allocated just perfectly,” but it might not be so hot when viewed outside the four wall of that users data center.  “We give others a chance to rank what they think is the right way, much like how Blog sites give others the ability to rank stories,” Simko said.

As is vKernel’s style, the site is designed so that it is simple to navigate and submit information to, allowing users to find similar profiles and compare them.

“It is a tool to help admins learn, share, and improve,” Simko said. “VKernel has only set up the framework of this site; we are not populating it or dictacting how people should be doing things.  It’s purely a community tool.”

I encourage you to check out the free CompareMyVM.com site and anonymously compare your VM resource allocation profiles with that of your peers. You will either feel pretty good about what you are doing, or really bad - and in that case, you’ll probably learn something.

PCI Data Security Standard updated, but still does not address virtualization

Last week I noticed that the Payment Card Industry’s Data Security Standard (PCI-DSS) was recently updated on October 1, 2008, from version 1.1 to 1.2. PCI-DSS is a security standard set forth by a conglomerate of all the major credit card companies and is designed to protect cardholder data. As a result, any company that accepts credit cards is forced to comply with it.

About six months ago I wrote that the PCI-DSS standard did not specifically address virtual environments, and instead only focused on servers and networks that are directly involved with cardholder data. In other words, the specification dictates what must be done to secure a server that may store or process cardholder data, but if that server happened to be a virtual guest the host server would not be considered in the scope of the specification. Subsequently you could secure a virtual guest all you want, but if you do not properly secure the host server you could easily compromise the virtual guest regardless of how it was secured.

I downloaded the summary of changes document that specified all of the changes that were made from version 1.1 and 1.2, anxious to see if they had finally added parameters for virtual host servers. Out of the 14 pages of changes, there was still no mention of virtualization technologies in the specification. Surprised by this, I searched through the whole version 1.2, 72-page specification document for the word virtual and found only one instance of it for virtual private network.

I am puzzled as to why they would continue to ignore virtualization. After all, isn’t just about every company virtualizing in some fashion these days? Are the people that write the specification parameters just ignorant of what virtualization is, and that it has a direct impact on their regulations? Or are they just trusting that we are all securing our virtual hosts properly and there is no need to address them? If that’s the case then they have misplaced a critical amount of trust as I am sure there are a great many virtual environments that are not properly secured. Likewise, ignoring virtualization completely greatly reduces the effectiveness of their efforts to secure environments that deal with cardholder data. It’s essentially fortifying everything within a castle, but leaving the front gate open.

It wouldn’t require a great deal of effort for them to address virtual hosts. A number of security specifications for virtual hosts already exist, such as cisecurity.org’s for VMware’s ESX. Let’s hope that they wise up and address virtualization in their next update of the specification. Until then their efforts to protect cardholders are not complete. I just hope that my credit card data is not lying on a virtual machine somewhere that resides on an insecure host server that is ripe for the picking. After all, why try and hack a single virtual machine when you can instead hack into a whole host and gain access to all the VMs and their data?

Making a P2V conversion: Tricks for systems with large storage

Converting a system with a large amount of locally attached storage can be a challenging task given the time required to perform the conversion. Here area a few tricks I’ve found that can help ease the pain on these types of conversion tasks.

• Private network: Making a private network between the physical host and the virtual host can provide two benefits. The main benefit is that conversion traffic will be isolated from the rest of the network traffic; the other advantage is that there is no risk of a user or process connecting to any resources and making changes during the conversion. The downside is that there may be special host-side configuration for a temporary network presence to allow the special network.
• Direct LUN mappings: For virtualization platforms that allow guest VMs to access a LUN directly, it can be much easier than performing a lengthy conversion of large data volumes that are already on a storage area network (SAN) and mapped to a physical system. Here is a blog post with a little more detail on that topic.
• Housekeeping: If there is junk on the physical system, does it need to be converted to the virtual environment, which may have more expensive storage? Clean up the candidate’s file system, and perform obvious tasks like emptying the Windows Recycle Bin. This allows for a more accurate re-sizing of the drives during the conversion.
• Agent backup and restore: For standard file volumes, such as a file server, it may make more sense to only convert the system drive and perform an agent-based restore to the virtual machine for the additional volumes. This does not necessarily save time from the entire conversion, but saves time within a tool like VMware Converter.
• Get a good time estimate: If you have to go at the large storage system as-is, make sure you have a baseline of about how many GB can be converted per hour. A good way to test this is to convert a good candidate system of about 100 GB and use that as a multiplier for your environment. There are a lot of factors, such as network speed and traffic, virtualization platform, storage systems (on both ends), and the conversion mechanism used. This allows for a good estimate on any downtime that needs to be coordinated if this applies to the selected workload.

These tricks can make converting a large amount of storage a little less daunting. What tricks have you employed to tackle physical systems with large amounts of storage in the course of being converted to a virtual machine? Leave a comment below and let us know.

The first 45 days of using the virtual machine expiration date

In prior posts, I mentioned that determining how the expiration of a virtual machine (VM) will be managed and implemented is just as important as deciding to have an expiration date. I have been using Emobtics V-Scout since its release in early September of this year, and it is one of the quickest and easiest ways to get started with a VM’s expiration date for free.

Depending on the technology climate, the concept of a VM’s expiration date may or may not be received well by internal IT teams such as developers. I have taken the stance that test-and-development systems should have an expiration date. The expiration date can be extended, of course, but it is more important that it is a defined process. Certain VMs will not have an expiration date, such as a QA environment for a live system. This can be managed in the same fashion as well.

In my experience thus far, I’ve found that the process makes the requesting development teams a little more aware of the system footprint. There has been little resistance to the concept of an expiration date, and it is well communicated from the virtualization team to the requesting groups. Using V-Scout, the procedural steps are to define the owner of the VM as well as the expiration date. When a VM is provided to the requesting group, I generate the V-Scout inventory report. The inventory report is then saved and sent to the requesting group as a way to clearly identify the definition of the VM in the virtual environment. The V-Scout inventory report comes with information about the operating system version, amount of memory, owner information and email address, expiration date as well as other information. With this information, the report adds an element of service credibility to the virtualization administrator. The figure below is a sample report from V-Scout:

Since I have been using the expiration date, the requesters of virtual machines have been proactive in letting me know that the VM needs to be extended in duration. I don’t mind accommodating that request, as I’m trying to avoid a long list of systems that in four years nobody remembers anything about. This proactive request for an extension is very welcome and stems from a few other small practice issues that accompany the VM expiration date. The most noticeable of this is an automatically scheduled email that reminds the requester that the VM is due to expire in one week. The other part of that is a scheduled task in VMware VirtualCenter to change the power state of the VM due to expire. Lastly, there is another scheduled email that reminds me to remove the VM from the virtual environment storage and Windows Active Directory.

These small practice points with the use of a tool that fits your needs allows for an expiration date to be implemented without using more expensive lifecycle or lab management products. V-Scout is a free download from the Embotics website.

Defining a nomenclature for storage allocations

The relationship between the virtualization administrator and storage administrator can sometimes be less than cordial. Yet it can become less contentious when approached in a certain manner. One way that administrators can work closer with storage teams is to identify a nomenclature for shared storage resources in the virtual environment. This is critical because as virtual environments grow, storage management becomes an extremely important part of a successful implementation.

In larger environments where the storage and virtualization server teams are separate groups, there are a number of ways to organize a standardized nomenclature of a logical unit number (LUN). For example, the virtualization admin may only care about the size of the LUN and possibly the tier of performance. The storage administrator is concerned about those factors and more. As I’ve mentioned in the past, the process of getting down to details in the storage environment is critically important as the infrastructure grows. As time goes on, we simply can’t refer to the “500 GB LUN” or “the last one you gave me” anymore.

Recently I had an opportunity to work with an entirely different storage environment than I’m used to. As can be expected, this situation arose, but I perceived it as a great time to hammer out a crude yet effective specification for a LUN nomenclature. The situation involved a VMware environment connected to a Fibre Channel storage area network (SAN) with a number of storage devices presenting disks to the VM environment. The basic objective of having a standardized nomenclature is so both parties can determine which LUNs are available and the basic information present on them. The figure below shows the end result of this ad-hoc policy:

Determining a nomenclature for storage allocations will vary widely for different environments. Designations such as which tier the storage lies upon, whether it is developmental or live system storage, or which virtualization cluster owns the storage can all be elements of the process. Furthermore, if you’re dealing with a storage management system, the requirements for the name of the storage system may be different than the directly attached storage system in the example above. The end result for all parties involved is a far more orderly process with a much better understanding of how the storage is allocated in the virtual environment. In addition, the virtualization team will be able to more clearly communicate with the storage team about specific resources in use.

ThinLaunch not all that impressive

At the New Innovators both at VMworld 2008 was an interesting small booth from ThinLaunch, which was manned by three of the four people in the company. I had a short pow-wow with two of the folks there and came away with mixed feelings. The product, for which the company is named, appears to fulfill a couple of interesting needs, the first being IT shops that want to pilot virtual desktop infrastructure (VDI) but don’t want to invest beyond the server room, and the second being smaller businesses that have server virtualization capacity to devote to hosting clients but have been loathe to rip and replace their thick clients with new thin hardware. I’m not too wowed by the product but I can see where it may be useful. That said, I was royally unimpressed with the technology.

ThinLaunch can be cobbled together with a few Group Policy object edits in Active Directory without buying the product. Simply replace the shell with whatever VDI launcher (or other application) you want. Microsoft tells you how to do it here. True, ThinLaunch then monitors this process if it crashes and can automatically restart it, but this is also something that can be managed with an application or by copying the code from this site.

ThinLaunch is available as an MSI package, meaning it’s very easy to deploy via Group Policy. Then again, Group Policies are even easier to deploy via group policy. Duh. ThinLaunch requires .NET 2.0. and GPOs don’t. ThinLaunch supports Windows 2000 through Vista and 2K8. GPOs do too.

I can see the need for this package and I can even see some large enterprise customers who’d want a packaged application to handle the conversion of legacy desktops. I can even see using the product in small businesses with virtualization already in place but a lot of legacy desktops and a lack of cash. What I can’t see is how it’s innovative in its approach.

Sorry, ThinLaunch, but you get three out of ten pokers — there’s just nothing hot there.

Server virtualization in the age of mergers and acquisitions

Last week at VMworld ’08, while living in the glitz of Vegas for a week of product news, press releases, interviews and judging the Best of VMworld entires with my TechTarget colleagues, my constantly buzzing BlackBerry delivered the latest financial news — the collapse of Lehman, the fall of Morgan, the implosion of AIG — all saying the doom of the market is upon thee.

As an investor, this wasn’t my happiest week (I always felt it was odd to invest money in people who invest money), but for a lot of others, last week must have been miserable indeed. Among those who are feeling miserable right now are IT staffers at Bank of America, who must now acquire a global IT infrastructure as their company acquires Morgan Stanley. And of course, federal IT staff are now worrying about how to oversee the essentially nationalized AIG. That’s not to mention the IT teams at numerous other companies engaged in mergers and acquisitions.

This is the time for server virtualization to shine. Bank of America should lead the charge in making efficient use of virtualization in their acquisition of Morgan Stanley. BofA is going to inherit an immense quantity of hardware, not to mention enormous heating/cooling/electric bills, colossal real estate costs and a titanic regulatory compliance project as it tries to integrate its own IT infrastructure with Morgan’s. If BofA (or any acquiring company for that matter) is smart, it will use virtualization to physical-to-virtual (P2V) every possible asset, transport to its own data center and import those virtual systems.

Bank of America shouldn’t just P2V low-hanging fruit, either — it should reach for the stars. Then it should shut down that physical hardware, wipe it and sell it to help offset the project costs. There are obviously a lot of nuanced steps involved in making this happen, but all the major pain points to which virtualization presents solutions are all the major pain points in integrating a new IT infrastructure:

1) Server move/change/add/remove
2) Power costs
3) Real estate costs
4) Heating and cooling
5) Configuration management
6) Asset management

The difference between the slow-rolling projects in most companies and the aggressive plan I recommend is night and day. The ROI in a progressive rollout can be achieved over time, integrated into the budget and then applied over that time. The costs of an acquisition and the integration of that acquisition’s IT assets are immediate and immense.

Virtualization can provide those long-term benefits in the short term — the elimination of real estate, cooling and power costs alone will offset the cost of licensing and storage. The enhanced backup and retention possible with virtualized systems will go a long way towards easing regulatory concerns of data retention.

Using blades as virtual hosts

Blades have come a long way since the early days of very few options and limited expandability. Most early blade servers only had one or two NICs, limited storage, no Fibre Channel support, and limited CPU and memory, which made them poor choices for virtual hosts. That’s all changed in recent years as blade technology has evolved and no longer has the limitations of earlier blades, making them ideal for virtual host servers. Modern blade servers can support up to 16 NICs, four quad-core processors and multiple Fibre Channel or iSCSI HBA adapters. When considering blade servers in your environment as an alternative to traditional rack mount servers, you need to know the advantages and disadvantages of each and why you might choose one type over another.

Some reasons you might choose blade servers over traditional servers:

• Rack density is better for data centers where space is a concern. Up to 50% more servers can be installed in a standard 42U rack compared with traditional servers.
• Blade servers provide easier cable management as they simply connect to a chassis and need no additional cable connections.
• Blade servers have lower power consumption than traditional servers because of reduced power and cooling requirements.
• Blade servers can be cheaper than traditional servers when comparing a fully populated chassis with the equivalent number of traditional servers.

Some reasons you might choose traditional servers over blade servers:

• Traditional servers have more internal capacity for local disk storage. Blade servers typically have limited local disk storage capacity due to the limited drive bays. Some blade vendors now have separate storage blades to expand blade storage, but this takes up additional slots in the blade chassis.
• Traditional servers have more expansion slots available for network and storage adapters. Blade servers typically have very few or no expansion slots. Virtual hosts are often configured with many NICs to support the console network, vmKernel network, network-attached storage and virtual machine networks. Additional network adapters are also needed to provide failover and load balancing.
• Once a chassis is full, purchasing a new chassis to add a single new additional server can be costly. Traditional servers can be installed without any additional infrastructure components.
• Traditional servers are often less complicated to set up and manage than blade servers.
• Traditional servers have multiple USB ports for connecting external devices and also an optical drive for loading software on the host. They also have serial and parallel ports, which are sometimes used for hardware dongles for licensing software. Additionally, tape backup devices can be installed in them. Blade servers make use of virtual devices that are managed through the embedded hardware management interfaces.

Many people that use blade servers as virtual hosts often take advantage of the boot-from-SAN feature so they don’t need internal storage on their blade servers. The choice between blade and traditional servers often comes down to personal preference and what type of server is already in use in your data center. Some people like blades, others don’t. Regardless of which server type you choose, they both work equally well as virtual hosts.

Managing the virtual machine lifecycle with an expiration date

Having a virtual machine expiration date is an important procedural step in successfully managing a virtual environment. Managing the expiration date in VMware environments is challenging without adding pricey tools such Lifecycle Manager or other commercial management products. In this video blog, Rick Vanover discusses one way to get the expiration date into your virtual environment without adding direct costs:

GlassHouse Technologies offers Managed Services for Virtual Environments

Today, Framingham, Mass.-based GlassHouse Technologies, an IT infrastructure consulting and services firm, launched Managed Services for Virtual Environments offerings. The new services are delivered through a management interface that uses virtualization management software from Dallas-based Tek-Tools‘ Profiler for VMware. This interface gives users visibility, monitoring and reporting capabilities for virtualized IT environments.

GlassHouse developed Managed Services for Virtual Environments based on the company’s experience in planning, designing and deploying effective virtualization strategies. GlassHouse noticed the need for more in-depth instruction for customers on how to maintain visibility, measure results and manage data center environments.

The complete Managed Services for Virtual Environments offering will be available later this year.

GlassHouse will showcase the capabilities of the new services at Booth 440 at VMWorld 2008 in Las Vegas Sept. 15-18.