Traditional server virtualization has the benefit of being able to adapt quickly to infrastructure changes over fewer physical hosts. So we should naturally be able to adapt new technologies easily, right? Not so fast, virtual server guy! This may be the tone many may face when looking at 10 GB Ethernet, also known as 10-GigE, for virtualization hosts.
10 GB Ethernet will be a fundamental component of the next generation datacenter. In fact, the new Cisco Unified Computing System will have a backend 10-GigE connection for the components.
But the reality is that many organizations are simply not ready for 10-GigE connections. The main reason is port cost for current and future switches. Most virtualization platforms currently have support for 10-GigE connections from the driver perspective; VMware environments have supported it since the base release of ESX 3.5. At this point, it may be a good idea to start considering purchasing hosts that have support for 10-GigE, even if the backend ports are not yet available.
Port and adapter issues aside, I can't wait for 10-GigE on the host. VM migrations would zip along, iSCSI networks would get a big boost in throughput, and any VM copy operations that utilize the network could perform faster.
The big question is, where is the money going to come from? The adapter cost and port cost is substantial at this point, and a higher cost burden is put on the network infrastructure. Spot-checking a few configurations for virtualization hosts, there is a price jump starting around $900 per 10-GigE port for common configurations. The network costs, however, are much higher per port when 10-GigE is introduced.
What should you be doing? Start the conversation with your network team (if a separate group) and get on your server hardware vendor to provide access to a product roadmap (under non-disclosure) to make sure you are making the right short-term and long-term decisions. I'm curious about adoption rates of 10-GigE among virtualization administrators.
Drop me a line with your approach to the next networking frontier or share your stance below.
Posted by Rick Vanover on 03/23/2009 at 12:47 PM1 comments
In many e-mails over the last few days, I simply used a subject line of 'The Benchmark' and everyone knew what I was talking about. Last fall,
Virtualization Review magazine Editor in Chief Keith Ward and I decided a bare bones hypervisor performance comparison was due, with Hyper-V joining the horse race in the server virtualization space. The end product was the comparative
performance test for VMware's ESX, Microsoft Hyper-V and Citrix XenServer.
It would be expected that there would be a naysayer or two in the crowd, mainly revolving on minor test details that don't accurately represent what a reader wants. The best example is that many commented directly to me and online on many sites that this should have been performed on shared storage. Other comments were made that torture tests of CPU, disk and memory operations have no place in virtual environments. Even the poor SQL database was incorrectly criticized for being a rouge agent. There were also comments that this was not an enterprise-level test, which I expected to an extent.
All of that and the associated community response to the piece seems to be missing one pivotal component. What was I out to prove?
I was not out to start a virtual war or single out a product in any direction. The test plan and piece was written for the typical virtualization administrator. We have CPU hogs and memory beasts that we want to get virtual, and the canned response of an application not being a virtualization candidate is a warning we may not heed by choice. We work with default configurations because we don't always have the time or other resources to go about it another way. We don't work with "camera-ready" databases. As a matter of fact, the database used in the test was a VMware vCenter database, which underwent some cleanup over and over --normal operations in my book. That's why I write the Everyday Virtualization blog, as this is what I deal with every day.
I think the test was a good thing, and should be a springboard for everyone to do their own internal testing. If you haven't already, share your thoughts
with me; if you want more of this, we'll do more.
Posted by Rick Vanover on 03/19/2009 at 12:47 PM2 comments
Last week, I
mentioned how administrators can take advantage of a licensing option for VMs that can save licensing on Windows Servers as guests. Through an unrelated event, I found some interesting
comments on VMware's Virtual Reality blog, where many relevant topics related to client licensing are discussed.
The first point is where Mark Chuang points out that customers who are considering any Hyper-V solution need to cautiously approach their licensing from the client access license (CAL) perspective. He hits a very important point here, as there are many changes with Windows Server 2008 and the CAL model. Among them is the new Windows Server 2008 terminal server CAL that goes along with new terminal functionality that can be rolled into virtualization solutions. My prior post only addressed the server licenses for datacenter consolidation; I specifically left CAL guidance vague as there are plenty of factors involved.
Chuang follows-up with this post highlighting a recent change in Microsoft's licensing that permits operating systems to run on a Windows Server 2008 system to run without a CAL for the "privilege" of being a Hyper-V guest. This is due to a recent change in Microsoft's licensing policy.
The takeaway is to never overlook the client licensing requirements. For Microsoft customers who go through the "true up" process (the annual recalculation of an organization's desktops, users and processors), CAL surprises are not a good thing, depending on the virtualization technology used as well as the OSes involved with the entire solution.
Are you having fun planning CALs in regards to your virtualization strategy? Use the comments space below to share any surprises you have discovered along the way or share them with me directly.
Posted by Rick Vanover on 03/17/2009 at 12:47 PM6 comments
VMware's vCenter (formerly VirtualCenter) is a critical system for most datacenters. Many early implementations had vCenter installed on a physical server, but it's not a requirement. VMware, with its own dog food on the menu, published a good
technical note on what you can and should do when virtualizing vCenter.
I've run vCenter in a VM for a small number of hosts and guests, and had no issues with it. I will soon take the plunge and virtualize a larger vCenter. To that end, I want to share some planning points.
The first thing I am doing is cross-management. The fundamental guideline is that a vCenter system is not managing itself in the hypervisors and guests managed. The typical installation is that vCenter 1 manages hosts that contain vCenter 2, and vCenter 2 contains the hosts that manage vCenter 1. This is a natural separation when it comes to test and development from live production systems, but this can make the migration or graduation process a little more cumbersome. In this configuration, I am gravitating towards something like vCenter Converter or these tricks to move VMs from one environment to another.
Beyond that, the other no-brainer is to keep the vCenter database on a system separate from the VM containing vCenter. This is outlined in the technical note mentioned earlier and fits well with my approach of keeping large SQL servers with many databases on physical systems.
In discussions with VMware technical resources and customers, whether vCenter should be physical or virtual has become a religious issue. I believe that it's a matter of preference and a reflection of how well virtualization is embraced in an organization. I say go for it.
Have you virtualized a large vCenter installation? Post your comments below or tell me what you have learned in the process.
Posted by Rick Vanover on 03/12/2009 at 12:47 PM3 comments
Microsoft's
Windows Server 2008 Datacenter edition offers unlimited virtualization rights. This means that you can put an unlimited number of Windows server systems as guest VMs on processors licensed with Datacenter.
That's good; but note that if you license a processor with Windows Server 2008 Datacenter, you don't actually have to run the Windows OS. Instead, the Datacenter-licensed processor can run a different virtualization solution on the physical hardware. One approach that many are considering is licensing the processor as Windows Datacenter, but running VMware ESX and vCenter (formerly VirtualCenter) to manage the systems. By buying both platforms, you get an open door to your Windows Server licensing for guest server systems.
Take, for example, a very capable host system by today's standards: a four-socket system with four or six cores each, with at least 128 GB RAM. That configuration can achieve rockstar consolidation ratios with ESX. While Hyper-V is a good hypervisor, as seen in the recent throwdown I did of each of the main platforms, I still feel that ESX will fit most mainstream IT needs. This is primarily due to the ability to get higher consolidation ratios on physical hardware and the current management products for VMware's virtualization offering.
Combine that hardware capacity and the licensing permission to run an unlimited number of Windows Server guest VMs, and you have a compelling cost-savings solution. The language of unlimited virtualization rights for Datacenter applies as follows:
- You can run ESX and other virtualization software on host processors licensed with Windows Server 2008 Datacenter.
- Windows server guests includes all versions and editions of Windows Server 2008, 2003, 2000 and NT.
- The client access licenses must still be purchased separately.
Many large enterprises already know this, but I'm mulling scenarios in my head where even the small and medium-size enterprise can take advantage of this configuration. Organizations of all sizes should consider this as a way to reduce the Windows Server licensing costs for guest VMs.
So, what's the catch from Microsoft's angle? I'm not entirely sure, but my suspicion is that Redmond is banking on the R2 version of Hyper-V making a real run at VMware in the datacenter by having organizations already licensed. If that happened -- assuming Hyper-V is "good enough" -- administrators may see an opportunity to cut the high cost of VMware and gain comparable functionality.
Are you taking this approach with licensing? Let me know how you're responding to the Datacenter opportunity.
Posted by Rick Vanover on 03/10/2009 at 12:47 PM5 comments
Earlier this week I
mentioned refining the basics of virtualization as it is now. I am going to totally change gears and talk about a next generation disk technology on the roadmap at VMware. The technology is called PARDA – proportional allocation of resources for distributed storage access. I came across this reading Cameron Haight’s
blog. Cameron is a research vice president at Gartner, specializing in virtualization and is a person I respect highly in the virtualization community.
PARDA proposes some very interesting technology, managed by the hypervisor. In the simplest terms, PARDA introduces distributed resource scheduler (DRS) for the I/O subsystem. PARDA is a software logic that manages access to disk systems without assistance from the disk controller in a fair access manner for a distributed environment. PARDA is explained in great detail in this VMware whitepaper.
This is an extremely interesting topic, as beyond the Nexus 1000V, disk systems are the next frontier to enhance in most virtual environments. PARDA’s key premise is to provide optimization and prioritization on disk systems that do not offer granular prioritization. PARDA has all of the inklings of traditional DRS – the concept of shares, awareness of multiple hosts and mathematical equations. PARDA also seeks to calculate the I/O managed per host when going to the same disk system. PARDA then works between the hosts to bring disk performance to a managed state where administrators can prioritize based on operational requirements.
Not all virtualized environments would necessarily benefit from this, however. Environments with larger storage systems that include advanced management and prioritization within the storage system may be able to provide elements of this functionality. These disk systems can generally assign greater priority and performance per logical unit number (LUN) or on selected fibre channel interfaces – but generally not by a specific VM within a LUN, mixed with other VMs of lesser priority.
I think this is the gateway to a new set of functionality for virtual environments. Check out the PARDA whitepaper and drop me a line with your take on this next-generation disk management concept.
Posted by Rick Vanover on 03/05/2009 at 12:47 PM1 comments
Last week’s
VMworld Europe show confirmed that new products are still coming. While we still don’t have a very clear picture of what the future will hold, now is a good time to clear up some loose ends in the current virtualization landscape before the changes start ushering in. Here are some points to think about in this transition time for VMware environments:
- Engage in a health check assessment. This small service can ensure that the fundamentals of your virtual environment are solid before any substantial changes are brought in. These services will vary by provider in scope, price, and deliverable, but are a good way to get an assessment of your environment from an outside perspective. These services are available by VMware directly, hardware vendors, software integration services, or analyst firms.
- Refine monitoring. Have you looked at available monitoring tools recently? There are some amazing tools out there, and many of them free. The virtual appliance marketplace and open source space are offering additional tools that can benefit almost any environment (more on this in a future post).
- Make your final push to remove older virtualized OSes. One pitfall of virtual environments is that the push to upgrade outdated OSes in the traditional sense is relaxed, as those virtualized OSes can effectively live forever. This may be a time to get older OSes like Windows NT and Windows 2000 VMs out, and upgrade to a more current OS. Future versions of virtualization products will drop support eventually for these products; vCenter Converter, for example, has already started this process.
- Training budget preparation. With a next-generation virtual environment on the horizon, it may be wise to get a budget lined up in this tough economic landscape. Even if a purchase is not on the horizon, I believe the training should be a priority for virtual environments.
This a short list of some things you can do it advance to set the stage for bigger and better things.
Send me a note with what your organization is doing to prepare, or share your strategies in the comments section below.
Posted by Rick Vanover on 03/03/2009 at 12:47 PM2 comments
VMworld Europe, in Cannes, France, is the focus of the virtualization community this week. While it's 4,400 miles away from me, it still is a source of important news for the virtualization community. Here are some highlights of partner and product announcements thus far at the show:
VMware and Fujitsu-Siemens have
announced that a new version of FlexFrame for SAP will provide a cost-efficient infrastructure for VMware-based environments. Fujitsu-Siemens computers are not marketed in the USA, so the news is more relevant to the attendees from the region.
VDI has taken a big step forward with the announcement of the VMware Client Virtualization Platform. This functionality allows Intel Core 2 and Centrino 2, combined with Intel vPro technology, to run a bare-metal client hypervisor and hook into VMware View. VDI has been a tough puzzle to put together for many organizations from the device perspective; this is definitely something worth checking out.
The vCenter Server Heartbeat feature was announced and will be available in March 2009 to provide continuous availability of the vCenter Server system. This complete solution will maintain the vCenter Server application, as well as the database via replication to another Windows Server. This feature has a relatively high price tag of just under $10,000 for an existing vCenter Server installation, or just under $13,000 for a new purchase of vCenter Server.
Wyse Technology announced that its entire line of devices natively support VMware View for VDI implementations. This is important, as selecting a device is one of the challenges faced in VDI. Wyse devices are nice in their central management by FTP server if configured. (By the way, be sure to check out this free tool to craft the FTP configuration files for Wyse devices -- this is simple and slick.)
VMware released vCenter Server 2.5 update 4. This update provides some fixes as well as enhanced guest OS customizations for Windows Server 2008 and a performance overview plug-in that consolidates CPU, disk, memory and disk information across multiple charts. This may be a precursor to ESX 3.5 Update 4, much to the liking of current customers frustrated by product issues of Update 3.
No discussion would be complete without something pulled out of the cloud. VMware announced the vShield Zones security appliance for comprehensive protection across a diverse computing environment. The security appliance would be a feature to the VDC-OS, and makes an important contribution to Payment Card Industry (PCI) regulations for compliance. Like other new products at prior VMworld events, vShield Zones is available for test drive in the hands-on labs at the show.
There is likely more to come from the show across the pond. Please
send me a note with your reaction to these announcements.
Posted by Rick Vanover on 02/25/2009 at 12:47 PM8 comments
One great thing about virtualization is
that there are so many amazing virtualization-centric tools available. Many good
tools are free; yet, for the rest, the pricing models end up being a
one-size-fits-most approach. Let’s identify the problem by highlighting the main
models for pricing of virtualization tools.
Among the more common
approaches is per-processor licensing, which is based on the number of sockets
available to the tool (which could span an entire virtual cluster). Per-use
licensing would have a price tag associated with each occurrence of the tool
being used; this can also refer to the number of systems managed by the
tool. Time-based subscriptions define a period of time that the software is
used. Lastly, various forms of enterprise licensing allow organizations
unlimited use for their environment.
The issue is that these are
greatly different strategies, and can end up with greatly different prices. For
instance, not all tools have the same value to an organization. Nor are all
virtual environments equal. The variance in pricing strategies led me to inquire
to vendors their opinions on the topic.
Alex Bakman, founder and CEO of
Portsmouth, NH-based VKernel, offered
the following on pricing: “We sell per socket because that is how VMware prices.
I think that small vendors should let the big boys establish licensing models,
as they have the power to move customers.” This makes sense to me, as the tool
price scales linearly with the size of the virtual environment. Many tools
follow this model now, but what about the future?
Bakman went on to
say “Longer term, I think we will need to move to per-core model, otherwise none
of us will be able to make any money.” Again, I’ll agree as six- and eight-core
systems may make administrators like me think about purchasing fewer
sockets in a system to save on licensing costs on all fronts. Further, tool
vendors need to make money, and protect themselves against virtual environments
that can circumvent licensing mechanisms. One example is Vizioncore’s vConverter, which must be
installed on a physical system to protect against VM copy operations to
circumvent the available per-use model.
This is a very relevant
topic in today’s cost-cutting economic climate. We want to do more with our
virtual environments and we need quality tools for the task. I am greatly
interested in your take on pricing models and the challenges you face. Please
share your thoughts on virtualization tool pricing below or email me your comments.
Posted by Rick Vanover on 02/23/2009 at 12:47 PM3 comments
On Feb. 12, VMware released version 4 of the popular
vCenter Converter tool.
Among the important new features are Linux conversion support, Windows Server
2008 support, some post-conversion task features, as well as enhanced image and
virtual format compatibility.
Many administrators take the P2V
conversion for granted, but in fact this is more important than ever, since
conversion tasks are growing in complexity and scope. One of the new features
that can assist administrators in this regard is workflow automation. This
allows an automatic shutdown of the source system and service management on the
destination system, so that data in transit can be protected. These types
of factors can make or break a successful conversion; to have it built into
the free product is a big plus.
But along with these new features and
platform support, be aware that vCenter Converter drops support for other
platforms. Windows NT 4.0 as a hot clone source is no longer supported,
and ESX 2.5 is no longer a supported destination. The previous
version of vCenter Converter includes Vista support (supported in version
3.0.3) as well as NT hot cloning and ESX 2.5 server support, so it may be worth
holding onto older versions to fill out the support matrix for your
environment.
It is important to note that this release is only for the
free, standalone starter edition of Converter. The enterprise edition, which
integrates with vCenter Server, isn't out yet. The full release of the next
release of VMware Infrastructure will likely incorporate some incarnation of
vCenter Converter Enterprise Edition.
vCenter Converter has been a
lifesaver for many virtual environments, and version 4 should continue this
trend into the next generation of VMware virtualization. Give it a spin and
tell me your thoughts on the version 4,
especially if you use the Linux conversion functionality.
Posted by Rick Vanover on 02/18/2009 at 12:47 PM1 comments
Sun’s
VirtualBox 2.1 hypervisor
has quietly passed an important milestone in its maturity. The bridged
networking that most VMware folk take for granted in a hypervisor is now
built-in. This makes it much easier to put a VM onto the same network as the
host. Before, VirtualBox required the use of the VBoxManage command to create a
bridged interface for guest provisioning.
Now, it could not be more
seamless. In the case of Windows hosts, the new VirtualBox host interface
networking driver (bound to the adapter) performs this important function. The
prior bridging functionality on Windows hosts implemented a spanning tree
algorithm by using the Windows network bridge, so this is a welcome upgrade for
network administrators. This feature is long overdue for VirtualBox, as the
spanning tree implementation may have put many off at first.
This is big news
for the free hypervisor, as fundamental features are the perfect layup for
bigger solutions. I recently
mentioned
how Sun is positioning their VDI 3.0 product for a strong end-to-end presence,
and VirtualBox is a big part of the solution. The 2.1 release ushered in other
features such as additional 64-bit support and full VMDK and VHD file support,
including snapshot features.
I have always liked VirtualBox, for a
number of reasons. It's free, the installation footprint is small, and the
feature set is in line with the competing products. The networking topic was my
biggest issue, and now that is corrected.
It's good news that this feature has landed in VirtualBox, even if it was late to arrive.
Let me know your thoughts on
VirtualBox if you have used it in any capacity.
Posted by Rick Vanover on 02/17/2009 at 12:47 PM3 comments
Hyper-V might be in its infancy, but its snapshot feature shows quite a bit of maturity. Basically, my gripe with most hypervisors is that when they make or remove snapshots, the burden on the guest is noticeable. Hyper-V is not immune to this, but what it does is pretty good. During a snapshot, a dropped ping can cause a problem for non-virtualization-centric notification systems and generate false failures. This can occur while the VM is taking or removing a snapshot.
In working with Hyper-V, I noticed right away is that there was only one lost ping in the snapshots I've taken. There was latency on the subsequent pings, but I saw only the single drop. This is important for production environments where snapshotting is used either as a backup mechanism or done before any sizable change. The only reason I am so focused on the lost ping count during snapshot operations is because of systems that may perceive the guest to be offline. Beyond that, many systems have timeouts for transactions that can be manifested by the slight delay.
And Hyper-V delivers on the other end in that the removal of the snapshot does not cause a lost ping. For VMs that have very large storage, this upfront and backside availability will become important as we will surely see VMs get larger as capabilities increase.
TechNet blogger Robert Larson has a good explanation of snapshotting as a whole and how it applies to Hyper-V but says, "Snapshots do not affect the running state of the virtual machine..." I beg to differ slightly on a technicality. When the snapshots are taken, there is a effect on the guest. Luckily, Hyper-V's implementation is pretty quick.
Snapshots, in most situations are not a key component to the everyday top-level virtualization tasks like VM migration, failover or management. Yet, they're convenient and their usefulness is clear.
Have you used much of Hyper-V’s snapshot functionality? E-mail me with your comments or share them below.
Posted by Rick Vanover on 02/10/2009 at 12:47 PM5 comments