Virtual machines, containers, functions. Market knowledge for IT decision makers since 2003
virtualization.info Editors New beta of popular WinImage disk utility introduces support for VMware virtual disk format: VMDK.
This way on both FAT and NTFS partitions you’ll be able to copy files from the VMDK file to host hard disk, while FAT partitions will also be able to receive files coming from host hard drive.
Gilles Vollant introduced similar support for Microsoft virtual disk format, VHD, at end of 2005 with WinImage 8.0.
Enroll for the beta here.
Quoting from the ClearCube official announcement:
ClearCube Technology, the market leader in PC blade centralized computing solutions, today announced an OEM agreement with virtualization software leader VMware to deliver a new PC blade virtualization solution for VMware Virtual Desktop Infrastructure (VDI). ClearCube is the first to certify its PC blade solution for VMware VDI. With its Sentral v5.5 management software, ClearCube now provides VMware VDI solutions that enable organizations to more efficiently manage physical and virtualized computing resources…
VDI market seems in continuous expansion but this trend may change as soon as VMware will formally announce Propero acquisition and will accoirdingly launch its branded VDI desktop broker.
Calculating how many Microsoft licenses you need in your virtualization infrastructure is not an easy task. Windows edition (Standard, Enterprise or Datacenter) can severely impact on final price and opportunity to grow. And back-end servers like SQL Server are part of this equation too.
To simplify this hard task Microsoft released a license calculator in January 2007, providing a simplified system to compare costs in three different scenarios where you are implementing different Windows editions.
After just 5 months Microsoft is ready to launch second version of this tool, still available for free as an online application, with a completely revamped approach.
Now users can literally build up virtual machines, filling them with Windows and Microsoft back-end servers they plan to deploy in production, and have a calculation of complete licensing costs of the infrastructure.
This new version is also able to calculate costs when you are using 3rd party virtualization platforms, including hosted solutions (like SWsoft Virtuozzo) and bare-metal ones (like VMware ESX Server).
Given this feature, Microsoft Virtualization Calculator becomes a mandatory tool in any virtualization project, and its highly recommended.
Access it here.
Update: Microsoft also published a 3-minutes demo of this new calculator which worth a check:
For June 13 (in Milan, Italy) and 14 (in Rome, Italy), LANDesk arranged a couple of seminars to introduce new application virtualization offering coming from OEM partnership with Thinstall.
I’ll speak at beginning of both events, talking about current situation of virtualization market and future trends, with a special focus on application virtualization.
If you are an italian virtualization.info reader I hope to see you there. Register for the event here.
(to see other events where I’ll have a lecture check my speaking schedule)
Embracing virtualization is much simpler to say than to do, mostly when you decide to migrate your existing production environment and not only creating from scratch virtual lab for small testing and development scenarios.
What’s behind an enterprise virtualization project and what issues IT managers will have to face during it?
In this long series we’ll identify which phases a virtualization adoption is made of, including:
If the virtualization market seems crowded today we’ll discover that is quite the opposite: it’s largely premature and several areas have still to be covered in a decent way.
Candidates’ recognition
The very first phase of a wide virtualization project involves recognition of physical servers to be virtualized.
This operation can be much less simple than expected and possibly is the most time consuming one when our company is missing an efficient enterprise management policy.
So one of the issues here is discovering and inventorying the whole datacenter.
A second point, none the less critical, is performing a complete performance measurement on the whole server population, storing precious data for the capacity planning phase.
This step is often overlooked because the IT management usually has a raw idea of what servers are less resource demanding and immediately believes it’s enough to go ahead.
Sometimes a benchmarking analysis reveals unexpected bottlenecks, depending on problems or simply bad evaluation of servers’ workloads.
The best suggestion in the first case is to immediately pause the project and proceed solving bottleneck: moving a bad performing server inside a virtual environment can seriously impact on the whole infrastructure, with subsequent huge difficulties in troubleshooting.
A precise calculation of performance averages and peeks is also fundamental for next phase of our virtualization adoption, the capacity planning, when will be necessary consolidating complementary roles on the same host machine.
After measurement collecting we have to identify good candidates for virtualization among inventoried population.
Contrary to what some customers could think (or some consultants could pretend) not every physical server can be virtualized at today.
Three factors are critical in deciding which service can go into a virtual machine: virtualization overhead, dependency on highly specific hardware, and product support.
Virtualization overhead is something future improvements of virtualization will mitigate more and more, but it’s something we still have to seriously consider.
I/O workload is a critical stop issue in virtualization adoption and some servers highly relying on data exchange cannot be migrated so easily.
Databases and mail servers are particularly hard to move in virtual infrastructures.
In both cases overhead added by virtualization on I/O stream is significantly impacting on performances, sometimes at a point that migration is discouraged.
But there isn’t a general rule on these or others servers’ types: it really depends on the workload.
There are case studies where customers achieved virtualization without any particular effort, others where the migration was successful only when virtual machines received double of expected resources.
The second stop issue is related to special hardware on which our production servers are depending.
At the moment virtualization products are able to virtualize the standard range of ports, including old serials and parallel, but vendors are still not able to virtualize new hardware components on demand.
An effective example, without going any far, is provided by modern and powerful video adapters, needful for games development or CAM/CAD applications, which are the most contested unsupported hardware at today.
The third stop issue in confirming a server as a virtualization candidate is product support.
The market is seriously considering modern server virtualization only in the last two years and vendors are very slow in stating they support their products inside virtual machines.
It’s easy to understand why: the amount of factors in a virtual infrastructure impacting on performances is so big that application behaviour can be severely influenced by something vendor’s support staff cannot control, or even know is present.
Microsoft itself, while offering a virtualization solution, has been reluctant supporting its products inside its own Virtual Server, and at today few of Windows Server technologies are still unsupported.
So, whenever your server seems a good machine for virtualization the final word depends on vendor providing applications inside it.
While every virtualization provider has its own, usually undisclosed, list of supporting vendors, it’s always better directly query your application’s vendor for a confirmation.
Going virtual despite missing support is a high risk to take and wouldn’t be suggested neither after a long period of testing.
From a product point of view in this virtualization aspect the market is still poor of alternatives even if candidates’ recognition problem can be approached by four kinds of specialists: hardware vendors, operating systems vendors, application vendors and neutral virtualization specialists.
Hardware vendors providing big iron for virtualization and offering outsourcing services, like IBM or HP, usually has internal technologies for recognizing virtualization candidates.
In rare cases these tools are even available for customers use, like the IBM Consolidation Discovery and Analysis Tool (CDAT).
Operating systems vendors are not actually providing tools for virtualization, but the trend is going to change very soon: all of them, from Microsoft to Sun, passing through Novell and Red Hat, are going to implement hypervisors in their platforms and will have to offer tools for accelerating virtualization adoption.
It’s not a case Microsoft announced at WinHEC 2006 conference in May a new product called Virtual Machine Manager, addressing this phase needs and more.
Application vendors will hardly ever offer specific tools for virtualization, even if they have more knowledge of anybody else to achieve the task.
The best move to expect from them would be an application profiling tool, featuring a database of average values, to be used in performance comparisons between physical and virtual testing environments.
A today’s concrete solution for customers comes from the fourth category, the neutral virtualization specialists.
Among them the most known is probably PlateSpin with its PowerRecon, which offers a complete and flexible solution for inventorying and benchmarking datacenter physical machine, eventually passing data to physical to virtual migration tools, which we’ll cover in the fourth phase of our virtualization adoption.
In the next part we’ll address the delicate phase of capacity planning, on which depends success or failure of the whole project.
This article originally appeared on SearchServerVirtualization.
In the previous article of this series we discussed the very first phase in every virtualization adoption project: recognition of best physical servers for migration inside a virtual infrastructure.
We saw how not every service can be virtualized and how some of them require special attentions. We also considered some available solutions to help in the task, discovering the virtualization market is still very poor in this aspect.
Once decided which machines will be virtualized we must move to the next, most critical phase of the entire project.
Capacity planning
What is capacity planning and why it’s the most delicate aspect of every project?
In this phase we evaluate distribution of virtualized physical machines inside physical hosts, dimensioning their resources, including processors type, memory size, mass storage dimension and type, redundant motherboard architecture and so on.
These machines have to contain planned virtual machines without suffer, have to survive more or less severe faults, depending on project’s requirements, and have to scale up easily.
In a medium complexity project chosen hardware doesn’t simply include physical servers, but means one or more storage devices, internetworking devices, network cards and cabling.
Every piece has to be chosen carefully and not for a performance need only: our decision will impact on next phase, when the return on investment (ROI) will be calculated, understanding if the project is worthwhile or not.
One critical value in hardware sizing is the virtual machines per core (VM/core) ratio.
Every virtualization platform has an expected performance level on the average, influenced by several factors, independents from the hardware chosen, from the virtualization engine optimization to the load virtual machine will have to handle. And the amount of virtual machines a single core (or a single CPU, in case of non-multicore processors) can support without problems depends on these factors.
So a VMware ESX Server 3.0 and a Microsoft Virtual Server 2005 R2 have a completely different VM/core ratio on the same host.
Why this value is so vague? The number of these factors is so large that it’s quite hard state a definitive ratio for a single product and virtualization vendors can barely provide an indication.
For example VMware states its ESX Server is able to handle up to 8 virtual machines per core, while its Server (formerly GSX Server) can handle up to 4 virtual machines.
But this numbers can be much higher or much lower depending on things like hosted application technology (a legacy accounting software written in COBOL is not what we call something efficient), I/O loads, etcetera.
Even if the value is so uncertain it’s still the most critical point in a virtualization project and it’s mandatory for a product comparison. Which is sometimes impossible: at the time of writing Microsoft has still to provide a suggested VM/core ratio for its Virtual Server 2005 R2.
Going beyond mere VM/core calculation, it’s mandatory to remember we are not going to virtualize a physical server but one or more server roles, so trying to size a virtual machine in the same way the actual physical server is could not be the best solution.
Given more than one host machine, a typical erroneous approach is consolidating virtual machines with the same logic of their physical location. So all production machines have to be virtualized in the first host, all development machines have to be virtualized in the second one, and so on.
It mainly depends on two factors: a natural desire to maintain what is considered a logical order, and a typical cultural bias, where physical location strictly relates to contained services (a way of thinking we’ll loose progressively towards our evolution to grid computing).
This approach usually leads to bad consolidations ratios: architects trying to cram several production virtual machines in the same host will find that machine overloaded by the huge weight of exercise services. Meanwhile another host, serving underutilized virtual machines, will waste most of its computing time.
So it’s pretty evident the big challenge of capacity planning is finding complimentary services to balance virtual machines allocation.
This operation has to consider several services factors, including expected workloads during all hours of a day, kind of physical resource requested, inclination to have very dynamic fluctuations, etc.
Obviously these factors can change over time, scaling up or completely mutating, so capacity planner must also try to forecast workloads growth, while in the enterprise management virtual administrators will have to rearrange virtual machines upon environment changes.
If this seems complex enough the biggest value still misses from the equation: acceptable performance level of every service.
This usually is the most overlooked aspect of capacity planning, giving for sure virtualized applications will always perform at their best. In the reality, even in the best arrangement, every software needs a certain amount of physical resources to perform in an acceptable way.
Capacity planning has to consider complementary workloads scenarios and must contemplate alternatives arrangements to always grant the expected performance for every service.
The task appears overwhelming but luckily part of it will be simplified in a near future, when all virtual infrastructures will be able to seamlessly and dynamically move virtual machines on different hosts, depending on their workloads.
VMware just launched this feature, called Distributed Resource Scheduler (DRS), within its new Virtual Infrastructure 3 (aka ESX Server 3.0 and VirtualCenter 2.0).
Microsoft expect offer the same capability with its upcoming Virtual Machine Manager tool.
This amount of factors can be partially managed today with help of few products.
The first and possibly most complete one is provided by the current market leader, VMware, which offers its Capacity Planner tool as a consulting service, available at fixed price of $22,000 for up to 200 servers.
The biggest benefit of this tool it’s the huge database where average performance values of industry applications are stored.
Based on these values the VMware Capacity Planner not only is able to suggest the best placement possible, but it’s also able to recognize troublesome applications, both at physical and virtual level.
VMware is not the only one offering this kind of tools: for example HP, with its Solution Sizer, and Sun, with its Consolidation Tool, are offering their customers a notable aid in this aspect of the project.
In both cases products are free but are tuned and locked for sizing just specific servers.
Once again PlateSpin PowerRecon, already mentioned in the candidates recognition phase, seems to be the most cost-effective solution for workload placement.
Thanks to its new Consolidation Planning Module it’s able to offer same capabilities of VMware Capacity Planner, minus the Industry Average database.
Its biggest feature is the integration with company physical to virtual (P2V) product, which we’ll see in the fourth phase of our virtualization adoption, offering a logical and integrated flow of actions during the initial steps of the project.
In the next part we’ll how the critical work of capacity planning translates in an economical value, justifying or not the entire project.
This article originally appeared on SearchServerVirtualization.
In the previous article of this series we discussed the delicate phase of capacity planning, where virtualization architects have to carefully evaluate which kind of physical machines will need to host all expected virtual machines, how this evaluation depends on specific arrangement strategies, and how heavily these strategies depend on hosted applications workloads.
The expenditure report will detail part of the investment a company have to face in its virtualization adoption and will be compared against a long list of cost-saving benefits this technology provides.
ROI calculation
This is probably the most critical part of the whole project and it’s the third one, not the first. This means a potential customer should arrive at this point already investing a significant amount of time and money just to understand if he really can afford the adoption or not.
The Return on Investment (ROI) calculation is done applying a simple math to a complex amount of costs our company could mitigate or eliminate once adopting virtualization.
The operation is not so trivial because some direct costs can be underestimated in the equation and indirect costs could not even be recognized.
Among direct costs virtualization can reduce we can include:
Some entries deserve a deep analysis which has to be reconsidered from project to project, given the incredible speed at which the virtualization market is changing.
Software cost for operating system licenses for example has not been a relevant entry until this year.
Using a virtual machine or a physical server didn’t change anything for customers deploying Windows, but Microsoft slightly changed its licensing agreement this year facilitating virtualization adoption.
At the moment owners of Windows Server 2003 Enterprise Edition are allowed to run up to four more Windows instances, any edition, in virtual machines.
The imminent Windows Vista will have a license permitting to have a second, virtual instance in virtual machine.
And license of upcoming Windows Server codename Longhorn Datacenter Edition will grant unlimited virtual instances of the operating system.
In a near future it’s highly probable Microsoft will further revise this strategy allowing unlimited virtual instances of the host operating system while they stay on the same physical hardware.
In any case all listed direct costs directly strictly depend on two factors we examined in the previous phase: VM/core ratio offered by the chosen virtualization platform, and most of all virtual machines arrangement we decided during capacity planning.
The better we worked on the previous step the most realistic situation we’ll have.
But whatever arrangement or virtualization platform we’ll decide, some important indirect costs should be calculated as well:
While these factors cannot be easily quantified they drastically change a return on investment calculation when dealing with virtual infrastructures.
Speed and effectiveness in deploying new servers with pre-configured environments, something usually called capability to perform, is unbeatable in virtual datacenters.
In the same fashion speed and effectiveness in moving the mission-critical applications from a failing hardware to a safe one, the so called capability to recover, is a basilar feature of virtualization and no security solutions can compete with it.
It’s evident ROI calculation is a hard operation to achieve and different interpretations could lead to very different results, leading to potential failure of our project.
To help potential customers, some vendors offer ROI calculation tools with partially precompiled fields, providing for example CPU/VM ratio values or products license prices.
It’s the case of SWsoft which offers an online form for its OS partitioning product, Virtuozzo.
In other cases skilled virtualization professionals transform their experience in useful tools, available for the whole community.
It’s the case of Ron Oglesby which created an Excel spreadsheet called VMOglator needful for evaluating virtual machines costs depending on physical hardware characteristics.
In most cases these self-service calculators aren’t really effective, both because aren’t able to track all concurring factors in the cost-saving analysis, and because customers are often unable or don’t have time to evaluate from themselves the real value of some expenditures.
The best option would be require a traditional ROI analysis, possibly from a neutral third party firm, but being a very time-consuming and expensive service few small and medium companies can afford to commit it.
At the end of this phase we have to have a list of costs for the current infrastructure, so called AS IS environment, a list of costs for the virtual infrastructure, and a list of costs required for the adoption, including:
These values are the final tools a company should use to understand if virtualization is approachable or not and in how many months it will have a payback.
In the next part we’ll enter the operational phases of the project, beginning from the very first step: transforming existing physical machines in virtual machines, through a process known as physical to virtual (P2V) migration.
This article originally appeared on SearchServerVirtualization.
In the previous article of this series we performed the last planning phase of our virtualization adoption project, the ROI calculation, discovering real costs behind project.
Now we finally enter in the first operational phase: the Physical to Virtual (P2V) migration of physical machines we recognized as good candidates for virtualization.
Candidates’ recognition has been discussed in the first part of this series, being responsible in providing mandatory data for subsequent capacity planning phase.
As we’ll see moving contents of a physical server inside a virtual machine often is a complex technical operation which requires time and costs money.
Physical to Virtual migration
Moving the whole content of a physical computer from its disks to a virtual machine is much more than simply copying files and folders from the starting location to a new position.
Virtual hardware presented by a virtual machine is always different from the one available on the original server and immediately after migration, at first reboot, operating system kernel recognizes new devices and look for drivers to handle them.
In the effort of adjusting itself for the new equipment a kernel not founding appropriate drivers stops to work completely, never reaching operational status.
Depending on operating system this adjustment implies more or less complexity.
Microsoft Windows is the most problematic operating system to move and it requires a helper to seamless fit new hardware.
A P2V migration tool passes to kernel needed drivers and initializes them at the right moment and in the right order, so that it can boot correctly and not show the freighting Blue Screen of Death (BSOD).
In Linux the adjustment is much easier and real experts would be able to perform it without commercial tools, but it’s greatly annoying and time consuming.
Also a manual operation wouldn’t be able to automate the remaining part of the process which involves interaction with the target virtualization platform.
In fact P2V migration tools not only have the responsibility to move data from source computer to target virtual machine and to accommodate the migration, but must be also able to create a new virtual machine with opportune virtual hardware, power it on and install required performance enhancement tools from vendor.
Market leader in this segment of the virtualization industry are PlateSpin and VMware, but other notable competitors exist, like Leostream and HelperApps.
Price of P2V migration tools is often considered very high by newcomers who relate them only to the mere operation to be achieved, without considering, for example, all costs related to unexpected errors in configurations where the physical server has been rebuilt from scratch in a virtual machine.
While in many cases the perception is wrong, PlateSpin is the first company approaching a new way to knock down potential customers’ diffidence: since September 2006 their P2V migration tool is available for rent, proposing a reasonable price per conversion even for smaller projects.
In any case an alternative approach exists: today several virtualization experts and enthusiasts offer free P2V migration tools but while they are good for converting few servers, at the moment no one is really able to scale for use in large conversion projects.
Customers usually discover very fast that amount of time spent to fix these tools when a technical issue appears is much more expensive than the cost per conversion in commercial solutions.
A needful add-on of modern P2V migrations tools is capability to interact with candidates’ recognition and capacity planning products.
Integration between these tools allows speedup of virtual migrations, since every just converted virtual machine can be immediately moved inside the most unloaded host server.
At the moment of writing PlateSpin is the only one offering such service, allowing its P2V solution, PowerConvert, to integrate with its PowerRecon discovery tool.
Desirable plus
A big plus when approaching P2V migration tools is considering their capability to perform the opposite process: a Virtual to Physical (V2P) migration.
While initially there is a prevalent need to consolidate machines, once embraced virtualization it’s easy turn to it for solving several different problems.
The huge administrative effort of deploying new workstation for employees, for example, could be greatly reduced if IT manager would be able to configure an ideal virtual machine and then inject it in brand new hardware.
Today this is partially mitigated with the help of disk cloning utilities like Symantec Save & Restore (formerly Ghost), but these solutions present a couple of severe limitations: they depend on hardware configuration so the same image cannot be restored on a different server, and any modification to the desired configuration implies saving a new master image.
The first limitation is being addressed these days by disk image companies like Acronis, which enhanced traditional cloning tools to restore images on different hardware, supporting also virtual machines, but in general a P2V migration tool also capable to do V2P operations could be the best choice.
Another feature we should look at when approaching a P2V migration product is its capability to perform the so called Virtual to Virtual migration.
A V2V migration moves OSes and their data between virtual machines of different vendors, taking care of differences at the host level and dissimilar virtual hardware.
As soon as multiple hypervisor will find their place in datacenters, bigger companies will have to address multi-vendor management and a simple way to move applications from a product to another.
Once again PlateSpin is leader here, already supporting V2V migrations back and forth between VMware, Microsoft and Virtual Iron virtualization products.
Avoiding downtime
Even the most efficient P2V migration tool has a big limit: it makes the physical machine unusable during the whole process.
The migration time is directly proportional to the size of local storage and network speed: on average a physical machine with a 72GB disk can takes up to 30 minutes for moving through a standard Ethernet link.
This could translate in a very expensive services downtime, which in case of mission critical environments or where a Service Level Agreement (SLA) is in place is not an option.
Luckily P2V technology is evolving and PlateSpin is already able to offer a live migration feature, completely avoiding the downtime.
This much desirable process is possible thanks to a special technique which handle copy of all files, including open and locked ones.
At the moment live migration is only available for Windows physical server but the company will add Linux support in the future.
A future of automation
In a near future candidates’ recognition, capacity planning and P2V/V2P/V2V migration tools will lose their original connotation becoming an intelligent, automated and autonomous service, dedicated to around the clock virtual datacenter optimization.
In perfect automation the candidates’ recognition component would scan 24 hours a day the whole datacenter, looking for underutilized physical server and overloaded virtual machines.
Every time one appears it would pass the report to the capacity planning component, which would suggest the best location where to migrate them: if a physical server is underutilized it has to be converted in a virtual machine, if a virtual machine is overloaded it has to be moved on a less busy host or converted back in a physical machine.
These orders would be passed to the migration component which would perform them seamless, without downtime.
At a point the whole environment will be completely liquid, changing its shape depending of every minute workload. And we’ll not even be able to distinguish if our services are served by a virtual or physical machine.
In our next appointment we’ll see the second, critical operational phase: the enterprise management, where we’ll have to face several challenges, including resources handling and monitoring, infrastructure automation and disaster recovery.
This article originally appeared on SearchServerVirtualization.
In the last part of this series we completed last phase of our steps towards virtual datacenter.
At this point we already performed an exhaustive capacity planning based on existing and expected workloads, decided which hardware equipment to adopt, and moved part or whole physical machines population inside virtual machines.
Now our efforts will be directed to facing complex challenges of virtual infrastructure management, including mandatory control of physical and virtual resources availability, usage and access; deployment of disaster recovery solutions; provisioning of new virtual machines and other tasks automation; and needful monitoring and reporting of datacenter usage.
Being modern virtualization still a very young market we’ll discover how hard is achieving such tasks, with immature tools and missing solutions, with a particular void in performance analysis and troubleshooting discipline.
Challenges of liquid computing
The very mandatory task of every IT manager, virtualization adopter or not, is management of existing resources.
Tracking physical machines usage, operating systems and products licenses availability, services attainability, helps understanding if purchased assets satisfy demand, and reacting fast when a fault happens.
This operation, which can be very consuming even on small environments, becomes more complex when working with virtual infrastructures.
IT managers have now also to worry about a new class of problems, like efficient and controlled virtual machines deployment, rational physical resources assignment, and in some cases even accountability.
Easiness in creating new virtual machines and their nature of independence from underlying hardware, leads to the idea of liquid computing, where it’s hard to exactly understand where is what.
This property increases risk of so called VM sprawl, a problem we had for in last 5 years with traditional computing, but with a much faster expansion rate.
To avoid it virtualization management tools should provide a reliable security system, where permissions can limit operators’ capability to create new machines, and a strong monitoring system, reporting on allocated but unused resources.
At today just the first one is implemented in most virtualization platforms, usually leveraging virtual infrastructure access with LDAP centralized accounting systems, while administrators still are in big troubles when they need to compute efficiency of virtual datacenters.
Going further, when a new virtual machine has been created the virtual infrastructure manager has the new problem of deciding where it has to be hosted.
As we already saw during the capacity planning phase in fact, virtual workloads should be deployed carefully, considering which already deployed workloads could be complementary, to avoid an overloading of resources.
Here management tools should help, assisting deployment after new virtual machines creation.
The upcoming Virtual Machine Manager from Microsoft for example will offer a rating system for available physical machines, assigning one or more stars to each of them so administrators immediately knows where a new virtual machine fits best.
This scoring system will adapt to the evolving infrastructure, even if sysadmins decided to not follow previous suggestions, so in every moment it provides best advices.
But even with such system, in some environments easiness of virtual machine creation may be not easy enough. For example, big ISP remodelling their hosting offering on virtualization are in need of smart tools to deploy hundreds or thousands of virtual machines on demand, in seconds.
At the moment few 3rd party products can fill all virtualization management holes, and many companies prefer develop in-house solutions instead of spending big money for little flexibility.
In such complex scenarios virtualization management solutions have to offer software development kits (SDK) allowing wide customizations and different degrees of automation.
A wide open programmable interface and a strong support are key selling points here and so far VMware did a pretty good job compared to its competitors.
Last but not least today’s IT managers have to face a very new problem: accountability.
In a medium complexity corporation, several departments may work with virtual machines and share same physical servers, using them in different percentiles during a fiscal year.
When each of these departments has a cost centre on its own, it’s pretty hard tracking who has responsibility for paying underlying hardware.
And even when costs are handled by a single entity inside the company, enforcing controls about who may use physical resources, and how much of them can be requested is very hard.
At the moment a short number of customers are addressing such kinds of issues, doomed to become common problems in few years, but who is already in trouble may want to see IBM offering, which pioneered the segment with its Tivoli add-on called Usage and Accounting Manager.
Multiple platforms, multiple issues
Mentioned needs further increase when a big company has to handle more than one virtualization platform.
In big corporation each department often has autonomy in choosing preferred solutions, even if only one product will be used for production environment.
So IT manager may need to concurrently manage VMware ESX server and Xen at the same time, hoping to leverage control with a single, centralized tool.
Market offering for such tools is multiplexing as request for them rises.
Solutions from IBM, Cassatt, BMC Software, Enomaly and Scalent are at the moment the most popular, but new contenders like Opsware are coming.
In many cases support for multiple virtual infrastructures means IT managers have not to worry about what technology has been used for creating a virtual machine: these tools are able to perform control and, where possible, application migration from a virtual hardware set to another. Something which is otherwise achievable only with dedicated P2V tools.
When choosing one of these super-consoles, it’s critical verifying they leverage existing management tools provided by virtualization vendors. Otherwise return on investment may never come.
This article originally appeared on SearchServerVirtualization.
In the last part of this series we took a look at how complex resource management in a virtual datacenter can be. But it’s just the first challenge administrators have to face when working with virtualization.
An even more delicate task, common in every infrastructure, is granting high availability of virtual machines, ensuring fast disaster recovery as well as reliable fail-over of faulty pieces in the environment: guests, hosts or storage.
Performing these operations is today more complex than on physical servers because there are new technical issues to address and market basically lacks of effective solutions.
Backup
In a virtual datacenter backup strategy can mimic traditional one, installing a backup agent inside every guest operating system and copying elsewhere files, partitions or the whole virtual disk.
This approach works flawless but has a painful downside when applied to virtual environments: each virtual machines uses same I/O channel offered by the host OS, so if multiple of them start their backup at the same time an I/O bottleneck is unavoidable.
To prevent it administrators should carefully plan a wave of backups, putting enough delay between them so that guest OSes never overlap during these intensive operations.
Unfortunately this method is not scalable and cannot avoid backup overlapping when there are more than a few virtual machines, considering each virtual disk has a size of at least 3GB, which can grow up to 10-20GB or even more depending on applications requirements, and may take hours to perform a backup.
Guest OS backup also obliges administrators, at restore time, to first recreate empty virtual machines and then boot a bare-metal recovery CD inside them.
An alternative approach consists in performing backup at host level, in a transparent way for guest operating systems.
Since virtual machines are self-contained in single files, dwelling on the host OS file system like a spreadsheet or a picture, virtualization newcomers may think backup is easier here, while instead it’s much more difficult, even if more desirable in many cases.
First of all virtual machines are considered just like open files locked by a process or an application (think about a .PST mail archive hold by Microsoft Outlook): these files must be accessed in special ways, freezing an image of their state (what we usually call snapshot) and performing the backup of it.
This task can be accomplished only if the backup software knows how to handle open files, even if in some cases it can be helped by the host OS: for example Microsoft Windows Server 2003 offers a feature called Volume Shadow Service (VSS), which can be invoked by 3rd parties solutions to perform snapshots.
Even knowing how to handle open files, we still have to face another challenge to perform a live backup: virtual machines are not just open files but complete operating systems accessing a complete set of virtual hardware.
Each time a state snapshot is taken everything freezes, including virtual memory and interrupts: this translates in the virtual world as a power failure, which may or may not corrupt guest file system structure.
Even if a robust OS doesn’t corrupt data on power failures, it’s an approach few vendors accept to support.
One of them we can find vizioncore, which funded its popularity around esxRanger, a product able to perform virtual machines live backup on VMware ESX Server with a fair grade of automation.
And for those brave enough to try such scenario even without support, there is the famous VMBK script, made by Massimiliano Daneri, which performs a basic live backup for VMware ESX Server virtual machines as well.
Microsoft will offer this kind of support for its Virtual Server 2005 starting from imminent Service Pack 1, but will not allow use of standard Microsoft Backup for the task.
The generally accepted approach, the only really endorsed by virtualization vendors to workaround hot shutdown issue, is to suspend or shutdown running virtual machines, perform the backup and resume or restart them.
Unfortunately this way prevents offering high available services and obliges administrators to use traditional agent-based backup approaches for mission critical virtual machines.
Putting aside live backup problems which will be eventually addressed as soon as operating system will be more virtualization-friendly, it is worth to note even this second approach stress a bit host I/O channels.
To completely eliminate the problem we have to move backup point from host to storage facility, where our virtual machines files can be manipulated without impacting on virtualization platform directly.
VMware has been the first adopting this solution but at today its Consolidated Backup (VCB) hs notable limitation since it works only with ESX Server, only acts as a proxy for real 3rd party backup solutions (obliging customers to configure and install different scripts for different products), and it’s not able to perform a restore.
Staying at the storage level a different method implies using SAN management softwares and invoking LUNs cloning, but this approach usually doesn’t provide enough granularity since the storage facility doesn’t natively recognize formatted LUNs and therefore cannot offer single virtual machines backups.
Recognition of LUN format depends on the storage management software we bought, and which file systems are supported.
It may recognize NTFS-formatted LUNs, allowing us to backup VMware Server for Windows virtual machines, while it could not support VMFS, preventing us from doing the same with VMware ESX Server virtual machines.
If the LUN format is unrecognized or simply we don’t have any enhanced storage management solution, we’ll have to clone the whole LUN, which contains several virtual machines, obliging us to restore all of them even if just one is needed.
Fail-overing and clustering
Obviously providing high availability in a virtual datacenter doesn’t only involve virtual machines backup. Like in traditional environment we should be able to configure clusters or at least fail-over structures.
But HA in virtualization can take place at two level instead of just one: we can work at guest level, relying on OS and application disaster recovery capabilities, or work at host level, facing a new kind of problems.
Implementing HA configurations at guest level is almost identical to what we already do in physical environments: there are some technical issues to address, like configuring a static MAC address for each virtual network interface, and some limitations, which depends on the chosen virtualization platform and on the chosen HA software.
But it’s basically always possible create a virtual cluster, or even create a mixed one, where one or more nodes are virtual machines while others are physical ones.
Much more complex, but much more needed, is providing high availability for hosts.
In such scenario, considering fail-over for example, virtual machines running on one host have to be copied on another one, and continuously synchronized, replicating virtual disks and virtual memory modifications.
This operation has same problems we already discussed above for live backup, but also adds complexity of doing everything as fast as possible and as many times as possible.
Here vizioncore is once again protagonist, with esxReplicator, able to copy running virtual machine from one VMware ESX Server to another, without or without a centralized storage facility. Unfortunately this product doesn’t handle network modifications needed to perform a real fail-over, so we have to manually switch between a faulty host and a cold stand-by one.
A more dynamic solution is provided by VMware itself, which introduced with ESX Server 3 and VirtualCenter 2 a fail-over option based on VMotion.
Unlike vizioncore esxReplicator, VMware HA automatically restarts virtual machines of a faulty host but it’s much more demanding in terms of configuration: it requires VirtualCenter and VMotion, and won’t work if VMs are not stored in a fibre channel SAN facility.
A different approach is possible thanks to physical to virtual (P2V) migration tools we already mentioned on a former part of this article.
Being able to perform also virtual to virtual migrations, we could configure them to replicate virtual machines contents from a host to another.
Here PlateSpin is the preferred choice at the moment, offering live migration for Windows operating systems and already oriented to disaster recovery use of its technology.
Unfortunately, just like vizioncore, PlateSpin doesn’t handle every aspect of fail-over so we still have to manually intervene.
Fail-overing is a good solution but surely the most desirable HA configuration is clustering, where multiple hosts act as an execution front-end for commonly shared virtual machines. If one of them goes down, there is no service interruption because virtual machines are always available through remaining hosts.
Clustering capability can be implemented at host level as native feature of virtualization platform or as 3rd party solution.
In Virtual Server case for example, Windows is the host OS and Microsoft grants virtualization physical nodes clustering through its Cluster Service.
ESX Server on the other side has not such feature but counts on external solution like Symantec Veritas Cluster Service to achieve the task. The recent acquisition of Rainfinity by EMC Corporation live some hopes one day Rainwall technology could be used to perform ESX clustering natively.
However at today clustering solutions for virtualization are far from being considered mature, and several customers are highly recommended to perform severe tests before adopting one.
Fail-over and clustering configurations are also complicated by different architectures: when virtual machines are moved from a host to another, they could be served by CPUs of different vendors, which are similar but not identical and current virtualization platforms are still unable to handle these differences in real-time, during a live migration.
In similar fashion if available hosts have different hardware configurations, virtual machines virtual hardware assignments may be not satisfied (think about a VM with four virtual CPUs), preventing migration at all.
This may get worst in a near future, depending on how vendors will implement support for paravirtualization.
As known this approach requires new generation CPUs, able to run host operating system at a special ring level. If the virtualization platform is not able to concurrently run both usual binary translation and paravirtualization, or if it’s not able to seamless switch between them, this will prevent using a mix of old and new physical servers, obliging to renovate the whole hardware infrastructure each time we buy new gears. Or to carefully decide how to aggregate hosts for high availability.
Last but not least we have to grant reliable access to the storage facility, which surely is the most critical step.
This is something usually addressed by the so-called multipathing: when hosts have aboard two or more HBAs, configured to reach more than one SAN, the storage management software knows how to prefer a working link among faulty ones, dynamically.
But being a software feature provided at drivers’ level there are some restrictions.
Depending on which virtualization platform you choose you may not have such capability: current architecture of VMware ESX Server, for example, doesn’t allow storage vendors to plug their own drivers, and provided ones doesn’t support dynamic multipath.
When choosing a hosted solution, like VMware Server or Microsoft Virtual Server, instead you are relying on the operating system to support OEMs drivers, which is always granted.
This article originally appeared on SearchServerVirtualization.