collective unconscious of the smarter planet

A good overview of how virtualization complicates traditional networking approaches - and how IBM is addressing the issue.

As virtualized servers become more prevalent in the data center, networking components such as switches must adapt to become more aware of virtualization. Most switches were originally designed for physical networks, in which LAN configurations were more or less static. When a new node was added or an existing node was moved to a new subnet, it often required a network administrator to make manual changes to the network configuration to ensure that requirements such as SLAs and security are maintained. As a result, changes to the network topology needed to be carefully planned in advance. With the rise of virtual infrastructure, in which virtual machines (VMs) migrate frequently from one host to another, it becomes nearly impossible for network administrators to keep up by making manual changes. IBM is now directly addressing this problem with the VMready technology that it acquired with Blade Network Technologies.

Server virtualization makes network management more complex, because VMs are hidden from the physical network switches by the hypervisor. VMs forward packets from the virtual network interface controller (vNICs) in the hypervisor to a virtual switch (vSwitch), and then to a physical NIC that forwards the packets on to the physical switch, which can only see the physical NIC. This setup works adequately until a VM needs to be migrated across multiple subnets to a new host. Although such a move is possible, it is not without issues and a network administrator must carefully plan out the move in advance so that the network policies associated with that VM, such as ACLs, QoS, and VLANs, follow the VM to the new switch.

To solve this problem, developers of server and network technologies have come up with various solutions to help networks bridge the physical and virtual domains in a way that allows them to adapt quickly and easily to changes on either side. IBM is now starting to promote one such technology, called VMready, which it obtained with the acquisition of Blade Network Technologies in 2010. Switches that use VMready allow VMs to be managed at the level of virtual ports in addition to physical ports. VMready switches sniff the network traffic between the hypervisors and management tools in order to determine the location and identification of each VM (alternately, the switch can send a query to a VM management console to determine the network attributes of VMs, such as UUIDs, MAC addresses, IP addresses, and VM names).

VMready management tools store the relevant data about all of the VMs they discover in a central policy database that contains information on every VM in the datacenter. For customers who need to set up the network in advance, a network administrator can populate the central VMready database manually. Once the database is populated, VMready allows VMs to be moved to any VMready switch on the network, and the defined policy profiles will follow the VM.

One of the nice features of VMready is the ability to create groups of VMs based on common Layer 2 or Layer 3 networking policies. For instance, VMs hosting databases can be assigned a higher Quality of Service (QoS) policy with Layer 2 redundancies, and web servers can be assigned a lower QoS without these redundancies. Once these groups are set up, detailed profiles can be assigned to each group, and these profiles will follow a VM wherever it may go on the network. When new VMs are created, they can be added to a group in which the relevant attributes will automatically be assigned to the VMs.

Standards for VM-aware networking are now being introduced, including Edge Virtual Bridging (802.1Qbg), which IBM helped to develop and champion.  IBM’s VMready 4.0 incorporates EVB, and, unlike some competing approaches, IBM’s VMready can be used with hypervisors from multiple vendors, and VMready switches do not require a separate management station or any special software to be installed on the hypervisor. Essentially, they function like normal switches, but at the virtual port level. IDEAS feels VMready will thus appeal to network administrators who have to manage increasingly virtualized datacenters, but also value compatibility with their existing physical infrastructure and heterogeneous virtualization software.

Some big advances in developing hypervisors for ARM-based server environments.

The Mobile Virtual Platform (MVP) hypervisor that VMware sells for smartphones and fondleslabs running the Android variant of Linux on ARM RISC processors is getting some competition.

Intrepid techies are working away on two different implementations of the open source Xen hypervisor for ARM chips, and another group is putting together a KVM hypervisor port as well.

Unlike the MVP hypervisor, which is a type two or hosted virtualizer, these Xen and KVM hypervisors are type one or bare-metal hypervisors that will be appealing to server makers pondering the possibilities of ARM-based machines. VMware rebranded MVP, which it got through its acquisition of Trango three years ago, VMware Horizon Mobile back in August, but everyone still calls it MVP.

The software is being demonstrated on schizophones that have a primary personality running in the host Android environment and a guest phone personality in the guest Android image running inside MVP.

MVP is not open source, and while Trango started out creating a bare-metal hypervisor for ARM devices, VMware backed off to type two because it was too difficult to keep up with the rapid pace of change in the mobile chip market - in terms of certifying for new chips and other peripherals as they become available from the legions of phone makers. Such certifications would slow down product introductions and eat into profits; it is much easier to let Android itself talk to these new chips and devices and have MVP present the same old virtual machine to the hosted Android apps.

A few weeks ago, Stefano Stabellini, a senior software engineer from Citrix Systems, and compatriots Tim Deegan and Ian Campbell, started hacking together a proof-of-concept Xen hypervisor for ARM machines, and on Tuersday Stabellini announced on the Linux Kernel Mailing List that they have put together a Xen hypervisor port to ARM’s Cortex-A15 reference chip. ARM Holdings, the company behind the ARM architecture, gave the Xen-on-ARM project an emulation board to do their development and testing.

“We started the work less than three months ago, but the port is already capable of booting a Linux 3.0 based virtual machine (dom0) up to a shell prompt on an ARM Architecture Envelope Model, configured to emulate an A15-based Versatile Express,” Stabellini wrote. “Now we are looking forward to porting the tools and running multiple guests. The code requires virtualization, LPAE and GIC support and therefore it won’t be able to run on anything older than a Cortex-A15.”

Stabellini says that the plan is to support other chips that are compliant with the ARMv7 architecture and that the project is looking ahead to support Xen on the 64-bit ARMv8 architecture, the initial specs of which were announced last month.

He gave a shout out to the Xen ARM Project being championed by Samsung Electronics, which is led by Sang-bum Suh from the chip and electronics maker. The Samsung version of Xen for ARM supports ARMv5, ARMv6, and ARMv7 processors – the earlier ones not sporting the virtualization extensions in the ARMv7 chips.

The Samsung approach uses paravirtualization – operating systems know they are running atop fake hardware and they stop acting like pigs and let the hypervisor manage their requests – and that means the operating systems have to be tweaked to allow for the lying that goes on between the guests and the hypervisor in such approaches. Sometimes, you can just paravirtualize device drivers instead of a whole guest operating system, and this is exactly what the Xen on Linux project started by Stabellini has done, thus limiting the number of changes to the Linux operating system to run atop this Xen implementation.

MVP and Xen are not the only hypervisors coming to ARM. Techies at Columbia University have put together the KVM/ARM project. While the Columbia project is working on propping up KVM on ARM Cortex-A15 processors and making use of the virtualization extensions in the chip, they have slightly modified Linux 2.6.27 and Linux 2.6.29 kernels running KVM atop ARMv6 and ARMv7 chips. The work on the virtualization extensions and on supporting multicore ARM chips still has yet to be done, according to the projects page.

You can bet that if ARM servers suddenly look like they will be taking off that Red Hat and Canonical will kick in some help and move these Xen and KVM projects along. Server maker HP, which has launched the “Redstone” experimental server line using Calxeda’s new quad-core EnergyCore ARM chips, might also help out. Dell has been playing around with ARM servers, too, and might help with the hypervisor efforts as well.

The performance costs of virtualization - “virtualization overhead” —

One of the dirty little secrets of virtualisation is the performance cost: operating systems running inside a virtual machine are slower than those running natively on the same hardware, sometimes by quite some margin.

This is termed virtualisation overhead, and with current whole-system virtualisation, it’s a given. It always happens. The question is, how much.

Back in the days of ESX Server 3, VMware itself admitted that integer performance suffered an overhead of up to six percent and more complex CPU operations up to 18 per cent. It claimed that Xen 3 was about twice as bad.

These days, things are not so serious, and the performance differential between the main hypervisor vendors has mostly evened out.

Stiff competition

Even so, bear in mind that this was on a single host with a single virtual machine. Contention for shared resources is also a significant issue, especially when it comes to disk storage where virtual machines often share a single drive or array.

Most current virtualisation on x86 is whole-system virtualisation: each virtual machine is a complete emulated PC containing a complete PC operating system. The virtual machine’s “disks” are actually files in a file system managed by a different operating system.

All the componentry of that nice uniform hardware platform that means you can move virtual machines from host to host – network cards, motherboard chipset, graphics adaptor and so on – is not nice fast hardware, it is software emulations running as part of the hypervisor.

Hardware extensions

Gradually, x86 chips are acquiring hardware extensions to assist in this emulation. The first generation of hardware virtualisation assist extensions was Intel’s VT, introduced in some of the last models of Pentium 4, the 662 and 672, in 2005. AMD-V followed with the Socket AM2 Athlons in 2006.

This hardware virtualisation merely allowed hypervisors to create a “Ring minus-one” – essentially, trapping Ring 0 (kernel-mode) code and running it though a software emulator. The CPU-intensive process of mapping virtual machines’ memory to the host’s physical memory still had to be done in software.

This changed in 2007 with the arrival of AMD’s second wave of hardware virtualisation, Rapid Virtualization Indexing (RVI), in the Barcelona generation of Athlons and Opterons. RVI provides the hypervisor with shadow page tables in hardware.

Page tables hold the map that translates addresses in an operating system’s memory layout to physical RAM addresses. But from inside a virtual machine, these emulated physical addresses are actually blocks of the host’s RAM. RVI’s second level of indirection accelerates the translation of memory addresses inside virtual machines to real physical memory addresses.

This makes little difference to a virtual machine’s pure CPU performance, but significantly enhances memory-intensive workloads, to the tune of 42 to 48 per cent.

Intel’s equivalent is called Extended Page Table and appeared with the Nehalem-family Core i3, i5 and i7 processors in late 2008.

For the moment, this is all hardware can do to help. The remaining techniques are a matter of software and system configuration.

In praise of paravirtualisation

Emulation is expensive so another good way to boost performance is to avoid it. From the virtual machine perspective, one way to do this is to modify the guest operating system or its drivers to be aware that they are running in a hypervisor.

For example, a guest operating system can be provided with special drivers that talk directly to the virtual network connecting the virtual machines to the host machine, rather than emulating a physical network card.

Similar methods can be applied to storage (such as SCSI and iSCSI), graphics, input devices and even memory management.

Microsoft calls this Enlightened I/O for its Hyper-V Server; support is built into Vista SP1, Windows Server 2008 and later, and drivers are available for Windows Server 2003, SUSE Linux Enterprise Server 10 SP3 and Red Hat Enterprise Linux 5.2 to 5.5.

VMware had a similar approach, the Virtual Machine Interface, which allowed Linux guests to communicate with the hypervisor, but this has now been outpaced by hardware virtualisation.

VMware also offers the vmxnet virtual NIC, as well as enhanced vmxnet2 and vmxnet3 drivers that offer TCP Offload Engine acceleration to virtual machines on suitably equipped hosts.

For Xen, there are PV drivers and for KVM, Virtio, which both offer analagous functionality.

Just passing through

The final, and in some ways most drastic, step is to avoid the emulation overhead by directly connecting virtual machines to physical hardware.

The simplest and theoretically cleanest way of doing this is by offloading storage, for instance, to a SAN; a virtual machine accessing a SAN in principle suffers no more slowdown than a physical server would.

As in the case of a physical server accessing storage over the network, though, this ideally means dedicating network interfaces to storage – which may mean adding multiple network interface cards to the host and configuring dedicated routes between virtual machines and networked storage devices.

Hyper-V also supports pass-through disks, where a virtual machine can directly control a dedicated LUN of a storage device on the host machine.

Windows Server 2008 R2 adds a new feature, Cluster Shared Volumes, which allows multiple hosts to share access to a single storage LUN, adding a degree of scalability to pass-through disks.

VMware currently takes the prize in this department, though, with its ability to directly dedicate not only SCSI controllers, but as of ESX 4, entire physical PCI and PCIe devices to a specific virtual machine.

The VMDirectPath feature allows one or two PCI cards in the host machine to be connected to the operating sysem running in a specific virtual machine rather than being managed by the hypervisor itself – from a simple USB controller to a dedicated physical NIC or storage device.

A slightly more modest optimisation is to place the swapfiles of Windows virtual machines directly onto the host’s vmfs storage.

There is always a price to pay, though, and this one is a biggie. There is a significant drawback in attaching dedicated devices to virtual machines, whether they are just disk partitions on the host server or physical interface cards and any attached devices.

Although such techniques can deliver pretty much full native performance, they hinder some of the key advantages of virtualisation: the ability to snapshot virtual machines for backup purposes, duplicate them and migrate them from one host to another.

At best, virtual machines accessing external, non-virtual resources often need to be shut down before migration, and snapshots must also duplicate any external resources – thus removing the scalability and fault-tolerance of virtualisation.

Differences of opinion

Virtualisation is now a key part of the x86 platform and it is not going to go away again. Further hardware advances will continue to improve speed and reduce overhead but there’s a long way to go before x86 servers can match the performance and scalability features of systems that have been doing virtualisation for decades, such as IBM’s System z mainframes.

On the other hand, paravirtualisation is also important. There are significant gains from having guest operating systems that know they are guests and can request services from the host server or its assistance in performing demanding operations.

Some of the possible improvements will probably remain limited by competitive demands, such as the different virtual machine formats of all the main hypervisor vendors and their totally different driver architectures.

Historically, such issues have receded either when everyone becomes compatible with Microsoft’s formats or the functionality moves into hardware.

That is still some way off for x86 virtualisation but it is a rapidly developing area, so watch this space.

The Register discusses some of the management issues that stem from virtualization. Good explanation of the types of pain-points that IT managers face everyday.

Virtualising systems often means scaling them up. Sometimes, disparate networks of machines are consolidated together, creating a mega-portfolio of assets. This carries a special set of technical challenges, but let’s not forget the managerial ones.

What happens when you scale a system by virtualising servers and cramming more of them onto more powerful hardware?

Your IT team finds itself having to manage a bigger volume of virtual machines, with all of the associated networking, performance and maintenance issues that it entails.

“If you are scaling and making things that you have to manage bigger, you will be stressing the processes and the individuals that do the work,” says Phil Everson, technology partner at Deloitte.

“It’s not just the case that you will need more analysts to cope. It may be that you can’t manage it in the same way any more.”

Human contact

What the head of storage architecture was able to do in a relatively small-scale system may change when that architecture suddenly covers several networks in different geographies.

If you have 50 people handling storage management across three data centres on two continents, it is not just the technological challenges that become more complex.

“Demand for scaling up from the business requires a much more mature bilateral set of communications,” Everson says.

“People have been trying and getting a bit better at it over the past decade, but it’s still an enormous challenge.”

This focus on solid, clear agreements with the business takes more rigour than you might think.

In the frame

“Does an agreement mean that it has been approved, or accepted? Does that mean there’s budget to do it? That there are people actively working on it and committed delivery dates?” Everson asks.

“Often, it doesn’t, and both sides miscommunicate as a result.”

Simple techniques, such as producing a register of all the projects currently being delivered in IT, can help here. Such a register could include a description of all the milestones planned for the next 100 days.

Management frameworks such as ITIL or Capability Model Maturity Integration can help organisations to manage infrastructures by refining processess. However, they are not a substitute for good IT management.

“They are an approach that drives the right nomenclature to enable good management. They don’t ensure that you have it, but they can help,” Everson says.

The same goes for automation, according to Brian Murray, principal consultant at IT services company 2E2. Manual processes are costly to implement, and as a system scales up staff become overworked and the cost increases.

Automation of manual processes can be a huge help, reducing error and cost. Processes ripe for automation include capacity management and automated storage tiering.

However, automation can backfire if these processes are detrimental to your IT management environment in the first place.

“If you are automating a process that is clunky and slow, then all you end up with is more of these problems, more quickly,” Murray says.

He highlights one process that can often be malformed from the start: patching and provisioning. This can often be done without proper patch testing, or it can be so bogged down in bureaucracy that it takes far too long to complete.

“If you look at how people make change management processes, mistakes are made, things are out of date, and it reduces confidence in that process,” Murray warns.

Getting some of the basic tasks right can give you a solid foundation on which to automate other processes. Configuration management can be mired in bad process, but if you get it right, and automate it effectively, it opens the door to a lot of benefits.

Automatically updating your configuration management database paves the way for more effective infrastructure management.

Blame game

The management problem is likely to become less tractable as we move further towards public cloud-based services, many of which may be mixed and matched from various vendors.

“When people moved to more modular managed services from large outsourcing deals, they had more contracts to manage,” says Everson. “That led to more finger-pointing when things went wrong.”

He believes we will face the same problems when we move to cloud-based services unless we have a solid management framework in place.

Overall, a focus on proper management at the outset as companies scale up their computing infrastructures will save a lot of headaches later.

Complex frameworks and rulebooks will get you so far, but you still need to practice management techniques on the ground, ideally including a mature relationship with the user base.

A fantastic, in-depth discussion of different virtualization methodologies from The Register.

Virtualisation has become an over-used buzzword.

On mainframes, it has been around for ages. Its introduction to x86 took a concept formerly reserved for Big Tech and let it loose among the masses.

Once a straightforward technology with a limited number of implementation models, virtualisation has been bootstrapped and shoehorned into every crevice of IT imaginable. Even smartphones are getting the treatment.

New capabilities do nothing for refuseniks who eschew the use of virtualisation. Some feel the need to evangelise this choice, while others loudly proclaim the “one true way” to use the technologies involved.

Direct-attached virtualisation versus distributed models is a common ideological battleground.

Direct-attached virtualisation is simple. A server with local storage hosts several virtual machines. These use the virtual switch (vSwitch) provided by the hypervisor to communicate with each other without having to send packets across the network interface card (NIC) and thus out to the rest of the network.

Talk among yourselves

Typically, virtual machines hosted in a direct-attached scenario are capable of communication with servers and clients located outside the host system, but most of the communication occurs among virtual machines residing on that one system.

Distributed virtualisation is very different. The host server is treated as much as possible as an entirely disposable processing unit. Storage is centralised and delivered to multiple hosts over a storage area network (SAN) with communication between virtual machines offloaded to physical switches.

Each model has its quirks.

Direct-attached virtualisation is fast. The maximum theoretical speed that a 10Gb NIC (a standard interface for modern SANs) could provide information is 1280 megabytes per second (MBps). A fairly common PCIe 8x 2.0 RAID card can theoretically provide up to 4000MBps.

Real-world numbers are not so clean. I’ve only ever got a 10Gb network attached storage up to 900MBps, and the best I’ve wrung out of my RAID cards (SSD RAID 10) is 2200MBps. But 2200MBps beats the pants off 900MBps, and handily demonstrates the storage speed advantage that the direct attached model can deliver.

Networking tells a similar tale. A hypervisor’s vSwitch provides each virtual machine with a virtual 10Gb NIC. This allows all the virtual machines located on a single host to chat among themselves at 10Gb, or faster if you feel like attaching multiple virtual NICs to a given virtual machine.

Tight squeeze

When heading off-host to the rest of the network, these virtual machines need to fight for the limited bandwidth provided by the hardware available. Having 30 virtual machines talking merrily away at 10Gb each is a completely different experience from asking those same 30 virtual machines to squeeze through a single 10Gb network card – and back again – to have networking processed by a physical switch.

Were we to consider only the numbers presented so far, distributed virtualisation would seem insane. But it has its advantages, and for many they are worth the cost.

What direct-attached virtualisation can’t do is rapidly move a virtual machine from one host to another. Virtual machines can be quite large, and moving the entire thing across a network can take a long time.

This is not an issue with distributed virtualisation’s centralised storage model. Distributed virtualisation also allows for live migration of running virtual machines between hosts.

High availability is another key selling point for distributed virtualisation.

Direct-attached virtualisation relies on robust, fault-tolerant virtual hosts for high availability. Distributed virtualisation senses when a host has failed and restarts all its virtual machines on other hosts in the cluster. The more hosts you have in play, the more the distributed model makes sense.

I can see you

Another benefit is that despite the speed bottlenecks, forcing all traffic through a physical switch gives network administrators visibility and manageability.

Enterprise-class networks run networking gear with tools providing end-to-end management straight down to the very last port. They can offer encryption between links, traffic isolation, monitoring, quality of service and a bingo card of other tick-box features.

All of that goes away the instant a vSwitch is brought into play. vSwitches don’t speak the same management language as the physical network providers. Instead of being able to control every packet to every system on the network, the closest you can get when using a vSwitch is control to and from the host servers.

Blurred outlines

Until recently, these two models were all we had. You picked the features that were more important to you and lived with your choices. This is unsatisfactory and in the grand IT tradition of nothing ever remaining sacred for long, hybrid virtualisation models have started to appear.

A new generation of NICs is starting to blur the lines, employing leading-edge standards such as 802.1Qbg, also known as Edge Virtual Bridging or Virtual Ethernet Port Aggregation (VEPA).

VEPA NICs are switches in their own right. When in use, virtual machines on a host bypass the vSwitch and talk directly to the switch integrated into the NIC. The NIC can talk to the management software, and now we have all the advantages of distributed networking without the bottleneck caused by having to send all virtual machine traffic out to the physical switch.

The competing approach to VEPA is 802.1Qbh, also known as Bridge Port Extension or VN-Tag. It is backed almost exclusively by Cisco, and requires an extension to the Ethernet specification, thus lots of new hardware.

This is a stark contrast to VEPA, which doesn’t require you to rip up and replace your network estate, and yet provides a viable solution to end-port management issues in virtual environments.

Configurations making use of both direct-attached storage and distributed storage in a single host are also beginning to appear. I have recently finished a deployment in which all hosts have a large amount of local storage to facilitate backups.

Each host has a virtual backup appliance (VBA) that takes live image-based backups of the virtual machines assigned to that host and stores them on the local buffer drive. This makes for very fast backups.

A central VBA reads the backups from all hosts and writes them out to tape during the day. The tape drive is mapped directly through from the host to the VBA rather than being a network-attached device.

This hybrid approach was not found in a whitepaper but born out of the necessity to make the best use of existing equipment. It has worked so well that, with refinements, I will re-use it in future deployments.

Perpetual movement

The continual introduction of new technologies into the mix will ensure that no virtualisation model stays static for long. IOMMU is the latest greatest, and promises to allow individual virtual machines direct access to system devices such as graphics cards.

Virtual machines will have the ability to tap into the full power of GPGPU computing, and will need to be fed data far faster than distributed technologies such as fibre channel can provide.

Advances in fault-tolerant hardware promise to make the individual host more reliable while new networking technologies push to 40Gb, 100Gb and beyond.

We have come full circle. Virtualisation started on the mainframe, and virtualisation is driving x86 to adopt technologies that bring it closer behaving like a mainframe.

Regardless of the similarities, there remains a fundamental difference between a mainframe and a cluster of x86 virtual hosts.

The mainframe is designed to be a single entity. Rack after rack, node after node, everything from the operating system to the interconnects binding individual nodes together, treats the mainframe as a single gigantic computer that is then sliced up for individual tasks.

An x86 virtual cluster is very different. Whether direct attached, distributed or hybrid, each processing node is very much a distinct unit. Each node matters: it must be configured, licensed and designed separately as well as with consideration to the whole.

A mainframe is an expensive computer that you custom-design software for: a high-performance system worth high-quality development. The x86 virtual cluster is a collection of cheap systems that you wrap around existing software.

A mainframe is what you build when you are running a financial system where milliseconds of latency can mean millions of dollars. It shines when you feed it applications that can break work down into small chunks and lots of small tasks in parallel.

x86 virtualisation, on the other hand, is a kludge.

It is our way of compensating for the fact that we are dragging around decades worth of software that is remarkably single-threaded, not very environmentally aware, and which needs to be insulated from other programs running on the same system.

x86 virtualisation models will continue to evolve because of this need to accommodate the sheer diversity of x86 applications.

There are many options available today to accomplish large amounts of computing efficiently. You can buy a mainframe or maintain a fleet of x86 systems with applications installed on the bare metal.

You can venture into x86 virtualisation and explore all the myriad different possibilities it presents. You could even lash together a few thousand cell phones into an incredibly awkward Beowulf cluster if you so chose.

There is no “one true way” to get the job done. The needs of your software and the capabilities of the hardware available to you will determine the implementation paths you can choose.

Some interesting statistics on virtualization from a vendor study.

Server virtualization is perhaps not as pervasive as many believe, and customers are not as locked into any particular hypervisor as many companies peddling this magic software layer might hope.

This info comes from the latest V-Index survey from Veeam Software, a maker of add-on management tools for VMware’s ESXi hypervisor, which is conducted on a quarterly basis in the US, UK, France, and Germany.

The survey only talks to fairly large companies – those with 1,000 or more employees. About a third of the companies surveyed had more than 3,000 employees. Veeam survey not merely its own customer base, but rather server shops at large, which also have other hypervisors.

In the September V-Index, 86.5 per cent of the 578 organizations that participated in the poll had some sort of server virtualization in their data centers. And across all enterprises, including those who did not have server virtualization at all, an average of 38.9 per cent of servers were virtualized, and they had an average of 701 servers in their data centers.

From the looks of the data, only x86 servers and hypervisors were part of the survey. This is a serious shortcoming, considering how much Unix and proprietary gear is still out there among large enterprises.

Just for fun, the V-Index survey asks companies how many physical servers and virtual machines they have, and then asks separately what consolidation ratio they are attaining on their machines. With the former, you can calculate the actual consolidation ratio, and the latter is – at least according to Veeam – the perceived consolidation ratio, which usually turns out to be higher than the actual consolidation ratio in the V-Index survey.

Across the four geographic regions and all the companies surveyed, the perceived consolidation ratio was 9.8 virtual machines per physical machine. But if you do the math and calculate the actual penetration ration, companies are actually squeezing only 5.1 virtual machines per host on average.

It could just be that some IT managers garbled their responses and have screwed up the data, but perhaps Veeam is on to something.

The penetration of various hypervisors on x86-based servers depends on whether virtualization is being used to run virtual desktop infrastructure (VDI) or more traditional server workloads.

On traditional server stuff, VMware still rules, with 67.6 per cent of those companies that have hypervisors saying that one or another flavor of ESX Server or ESXi is their primary hypervisor, with only 14.4 per cent going for XenServer from Citrix Systems, and 16.4 per cent opting for Hyper-V from Microsoft. Red Hat’s KVM is tossed into the Others category, which accounted for a meager 1.6 per cent.

When you shift to talk about hypervisors running on servers to specifically stream VDI desktops, then XenServer is cited by 24.9 per cent of shops as their primary hypervisor, Hyper-V by 20.3 per cent, and ESX by 54.2 per cent.

Now here’s the interesting bit: 38 per cent of companies using virtualization for traditional workloads say they are planning to change their hypervisor during the next year.

The cost of the current hypervisor platform was cited as the main reason for the jump by 58.9 per cent of the jumpers, with nearly half saying that they didn’t like their current vendor’s licensing model, and they did like the features offered with alternative suppliers or that the alternatives had matured enough that they could contemplate making a shift. While VMware was not mentioned specifically by name as the one that companies were thinking about ditching, KVM, Hyper-V, and XenServer have been in catch-up mode for a while, and have largely caught up.

But of course, VMware is focused on cloud fabrics and infrastructure and platform clouds, areas in which Citrix, Microsoft, and Red Hat are playing catch-up.

Forrester has just released a meaty report on the top trends for enterprise architects. Here’s a synopsis from ReadWrite Web.

The 10 technology trends on Forrester’s watchlist through 2014 fall under four categories: Application platforms, integration, infrastructure and operations, and mobile computing.

The Big 10

Forrester rates each technology trend by IT impact, business impact, newness and complexity. According to Hopkins’ report, enterprise architects have their work cut out for them for the next few years. All but three of the trends are judged to be of high or very high complexity.

Under the application platforms category, Forrester predicts that companies will be dealing with elastic application platforms and wider adoption of Platform-as-a-Service (PaaS). The PaaS trend probably needs little explanation. Forrester is predicting that it will “cross the chasm” to wider adoption. As for elastic platforms, Forrester is predicting that enterprises will be seeing more applications that enable scaling by workload. Forrester says companies need to be getting ready with scale-out storage, parallel processing and horizontally scalable databases.

Integration

In the integration category, Forrester is expecting data services and virtualization to “reach critical mass.” The firm is also predicting that better tools will enable “holistic integration” that will allow firms to “work on application, process, and data integration with a minimum of technology overlap.”

Finally, Forrester says that “social technology will become enterprise plumbing.” According to Hopkins, tools like Yammer, Salesforce Chatter, and Socialtext will make social interaction part of normal workflows.

Infrastructure and Operations

If you’ve been paying attention to ReadWriteCloud, the infrastructure and operations categories predictions will look very familiar.

Forrester says that improved virtualization is going to be setting the stage for private clouds, and that network architecture will be evolving to meet the demand for cloud. The third trend to watch in this category, says Hopkins, is that “always on, always available is the new expectation.” No argument here. Actually, I’d say that “always on, always available” has been an expectation for quite some time. Whether services live up to it or not is another story.

Mobile Computing

Forrester calls out what we’ve been observing for some time in the mobile computing category. The first trend here is that enterprise mobile platform strategy is going to change due to personal device momentum. In short, users will increasingly be bringing their own phones and expecting to use them. Forrester notes, correctly, that this will continue to be a problem for asset management and security.

Finally, Forrester says that the “app Internet will usher in the next generation of computing.” In short, Forrester is giving enterprise architects a heads-up that apps are becoming more specific, location and context-aware.

Red Hat has been joined by some major heavyweight - including IBM, Cisco, and Intel - to push a more full-featured version of KVM as an alternative to VMware.

Red Hat is taking on VMware with five enterprise heavyweights through a vendor-neutral virtualisation community project based on its RHEV-M stack.

Red Hat has been joined by Cisco, IBM, Intel, NetApp and SuSE to lead oVirt Project, planning on building a pluggable hypervisor management framework along with an ecosystem of plug-in partners around its virtualisation management tool for KVM.

To seed the project and motivate the community, Red Hat is releasing the RHEV-M code to oVirt under an Apache Software Foundation (ASF) licence.

oVirt’s official launch is in early November, at a workshop day that will be hosted by networking giant Cisco at its San Jose, California, campus. The ASF’d RHEV-M code will be released to Git repositories at this event. Today oVirt consists of 13 projects with the expectation for another two to be added by November…

The Linux distro vendor now hopes the OVA will become heavily involved in marketing oVirt. Joining Red Hat at the OVA launch earlier this year were IBM, Hewlett-Packard, Intel, Novell, BMC, and Eucalyptus Systems; today OVA claims more than 200 members.

The idea behind oVirt is to give people who want an alternative to VMware more than just the choice of going with a Red-Hat subscription for RHEV-M or using Microsoft’s Hyper-V, Red Hat told us.

“This will make things radically different,” Red Hat technical director Carl Trielof told The Reg. “Massive adopt of the technology as an alternative to VMware can only be a good thing.”

“This is going to be the first open and openly governed community that’s an alternative to VMware,” he continued. The watch word here is “OpenStack”, the open-cloud project Red Hat didn’t participate in because it disagreed with a governance model and direction dominated by a single company: Rackspace.

oVirt has been in development for three months with Red Hat working on the governance model in with the other five according to Trielof.

“We are not owning the community as Rackspace did around OpenStack. If we really believed there should be an open virtualisation solution then the first question is not what’s best for Red Hat, but it’s what’s best for the community and the user base. If the project thinks in those terms… then it’ll be good for us and everybody.”

Red Hat won’t lose out by putting RHEV-M into the community, he claimed, because the company will continue to sell enterprise subscriptions to the hypervisor and management software. He drew an analogy between Red Hat’s patronage of Fedora and its use as part of the company’s Linux distro.

Trielof said the oVirt Project is being set up as a hybrid of Apache and Eclipse: the former being a place that hot-houses projects and elevates individuals to leadership roles based on their contributions to projects while the latter is based on the ability to build a technology framework that’s enriched through a lively ecosystem of plug-ins from ISVs and individual developers. ASF founding member Jim Jagielski is helping on oVirt board to get it established.

Red Hat went with an independent organisation rather than dropping the oVirt projects into Apache because some features in the KVM are under the GPL and LGPL.

Also, there’s no opportunity in Apache to release the hoped-for 15 oVirt projects as an integrated release – projects would have to be developed separately.

Trielof added that Red Hat wanted to create a brand and a location for the community rather than simply shunting it into Apache.

The vision is to emulate Eclipse, not just from the perspective of having an ecosystem of plug-in providers, but also in terms of delivering an integrated platform composed of projects and technologies.

Eclipse now provides an annual synchronised update for many of its projects to remove bugs and give those using and developing products on Eclipse a reliable platform. Eclipse in June put out its biggest single release so far: 62 projects, or 46 million lines of code.

Eclipse was kick-started by IBM in November 2001 as a community and technology project. IBM primed the project by donating $40m worth of source code from its Websphere Studio Workbench to create an open-source framework for Java and C++ server-side development.

The idea, on paper, was to build an open IDE framework that didn’t lock in tools partners and that saved ISVs from having to constantly re-invent the basic building blocks of IDE such as syntax editors.

Red Hat was among the founding members of Eclipse with IBM, SuSE, Borland Software – now owned by MicroFocus – TogetherSoft, borged by Borland, and others. The group expanded quickly, hitting 80 members by the end of 2003, ultimately pulling in Oracle and SAP. By the late 2000s when it came to tools, the world was represented by Eclipse on Java and Microsoft on .NET.

Eclipse consolidated IBM’s WebSphere while putting some tools vendors, like Borland, out of business and driving others into the arms of IBM. Eclipse broke out of being just an IDE project for the server in into PC and web development, business intelligence and even runtimes.

If oVirt is successful the Eclipse model might prove a burden for Red Hat as well as hurt VMware. For all the success of Eclipse and its long-list of community members, it’s been IBM that over the years has consistently provided most of the manpower and code commits.

That has meant while Eclipse has helped IBM’s Java business, IBM has been left pick up the bill on development while struggling to sell paid-for tools against Eclipse, whose price point starts at zero dollars.

Chuck Hollis looks at how virtualization is changing the way that organizations design and provision databases. His focus is obviously VMware, but it’s an interesting discussion nonetheless…

Inexorably, virtualization is changing how we think about every aspect of IT.

It’s already vastly changed how we think about physical IT infrastructure: servers, storage and network. 

From static allocations to dynamic pools of resources – without VMware’s popularity, we really wouldn’t be talking much these days about cloud and transforming to IT to a service.

But what about databases and data management?  

Clearly, many of these technologies haven’t made the transition to the new model.  At best, we’ve only been able to encapsulate and containerize legacy databases using virtual infrastructure vs. revisiting how databases might intelligently work in this new model.

How do we get databases to intelligently use dynamic resources?  How do we deliver database as a service?  And how do we make databases as easy to consume as other forms of infrastructure?

…

Today’s Databases Were Designed For A Physical World

The more you look, the more you realize that the vast majority of databases in use today were designed to operate in the physical world, and not the virtual one.  And that’s far from ideal.

One immediate example is the lack of dynamic resource utilization.  All databases use precious resources: memory, CPU and storage.  Even though most database workloads are extremely variable, the vast majority of databases expect a big, fat over-allocation of these resources – they’re not smart enough to request more when they need it, and give it back when they don’t.

Any “virtualized” database should be smart about the environment it’s running in – smart enough to request and release resources as circumstances change.

Another example is the absence of integrated provisioning using standard templates and workflows.  

Today, provisioning infrastructure can be dead simple on something like a Vblock: the administrator defines standard infrastructure services and templates, and creates or changes resource instances using a very high level of automation.

This isn’t true for provisioning new database instances – it’s still mostly a manual process that requires hands-on work by an important and scarce resource – the database administrator.   Any “virtualized” database should be as easy to provision as a virtual machine.

A final example might be the need for self-service portals.  In the infrastructure world, using products like vCloud Director, it’s easy for administrators to expose resources to anyone at all: other IT groups, even end users.  A simple portal explains your choices, collects your details, and gives you what you want: typically with little or no human intervention.  

More importantly, the system administrator is additionally armed with powerful tools that help manage the pool of resources: allocation, service levels, and so on.  Again, if we’re talking fully virtualized databases, the same generic model should apply.  

Consuming a new instance of a database should be as conceptually simple as consuming a virtual machine.  And managing pools of databases ought to be as straightforward as managing pools of virtual machines.

Ideally, virtualized databases would support dynamic resource usage, integrated provisioning and self-service pooled consumption models.  But, outside of a few exceptions, that’s not the case today.

Dynamic Resource Usage

One of the first things that leaps out of the announcement is the virtual enhancements the VMware team has made to the popular PostgreSQL database.  At the outset, a “balloon driver” is able to request and release memory based on changing circumstances.  The same sort of capability seems to be there for GemFire.  The announcement is pretty clear: more options coming over time.

Extending this idea a bit, it would be logical to assume that – eventually – this concept could include to storage performance (perhaps using a variety of mechanisms that are extensions of VAAI: linked clones, Storage vMotion and/or storage service pools) —  creating and releasing additional database storage instances (or perhaps relocating them to different storage tiers) thereby increasing or decreasing performance.  The same expand/contract potential exists for dynamically using virtual or physical cores.

I have observed that massive over-provisioning seems to be the accepted norm in the database world: overprovisioning on memory, overprovisioning on storage performance, and overprovisioning on CPU.  

Wouldn’t it be wonderful if databases were smart enough to take what they needed to meet changing service level requirements, and no more?  If they had the same elastic properties as other portions of the infrastructure?

That’s the goal here.

Integrated Provisioning

Everyone who has had the pleasure of doing physical server provisioning knows all of the sequential, labor-intensive and occasionally error-prone steps involved.  

Indeed, anyone who’s working in a fully integrated virtualized environment (such as a Vblock using UIM) probably doesn’t want to go back to the old way of doing things anytime soon.

Indeed, in these new environments, valuable system administrator time is now spent on more worthwhile, higher-order tasks vs. the drudgery of before.  

The database administrator in many regards is no different – their time is important as well, and they could greatly benefit from the same sorts of capabilities: far less time doing sequential, labor-intensive and occasionally error-prone grunt work; and far more time tackling the more interesting challenges and opportunities.

I haven’t had the opportunity to look at the new vFabric Data Director in gory detail, but from what I can see from the overviews, there appear to be the same sort of templates and automated workflow concepts you see in virtualized server provisioning workflows.

Ease Of Consumption

Today’s pooled and virtualized environments are designed to be easy to consume — that’s what the whole “as a service” thing is about.  

Popular request types can be easily exposed on a portal, and people can get what they need with an absolute minimum of human intervention.  Behind that, resource administrators now have powerful tools that help manage and control the pooled environment in aggregate.No such luck for most of the database world today.  

Getting (or changing) a database instance almost always involves tracking down a database administrator and asking them to do something on your behalf.  And, while database administrators have the tools to manage individual database instances, there’s not much out there that addresses their need to manage and control hundreds or thousands of database instances being delivered as a service.

That changes with the new vFabric Data Director.

Digging Deeper

I think once the novelty wears off, most IT thinkers will realize a few simple truths.

First, there’s a big and obvious problem to be solved here.  

I routinely meet customers who have hundreds and occasionally thousands of database instances swirling around their environment.  Telling people not to create new databases just means they’ll go elsewhere.  Not good.

And no one has the stomach for a massive “gee, let’s go consolidate a bunch of existing databases into a single humungous instance” project.  At least, not twice :)

The only viable approach for many?  Use virtualization techniques to lessen resource usage, control service delivery and manage the pool of database instances more efficiently.  Just like you do server instances.

Second, while the technology is capable of supporting demanding workloads, that’s not where it’s going to be used first.  Just as with server virtualization, the most appealing initial target will be non-critical database workloads vs. the big hairy stuff.   Make no mistake, that too will come — in time.

Third, the underlying hybrid cloud model is extremely relevant here.  If you think for a moment about external database and PaaS offeirngs (e.g. AWS, Azure, et. al.) there’s only one consumption option for each: their particular service.  Easy to get in to, somewhat more difficult to get out of …

Compare and contrast this with the vFabric Data Director approach where you’re free to set it up internally, use any number of compatible external service providers, or any particular combination that suits you.  

Fourth, I’ve met more than a few people that are looking for a different industry model to deliver database services to the business vs. buying more of what they already have.  Here’s a model that’s worthy of serious consideration.