Virtualization - Ask the Experts #4

Our Ask the Experts series continues with another round of questions.

A couple of months ago we ran a webcast with Intel Fellow, Rich Uhlig, VMware Chief Platform Architect, Rich Brunner and myself. The goal was to talk about the past, present and future of virtualization. In preparation for the webcast we solicited questions from all of you, unfortunately we only had an hour during the webcast to address them. Rich Uhlig from Intel, Rich Brunner from VMware and our own Johan de Gelas all agreed to answer some of your questions in a 6 part series we're calling Ask the Experts. Each week we'll showcase three questions you guys asked about virtualization and provide answers from our panel of three experts. These responses haven't been edited and come straight from the experts.

If you'd like to see your question answered here leave it in the comments. While we can't guarantee we'll get to everything, we'll try to pick a few from the comments to answer as the weeks go on.

Question #1 by AnandTech user mpsii

Given that more is better, when considering budget constraints, are more CPU cores better than more systems (one hexa core vs 3 dual core systems)? Or, is one system with 32 GB of RAM going to perform better than 2 systems with 16GB of RAM?

Answer #1 by Johan de Gelas, AnandTech Senior IT Editor

If you like to use virtualization to run several small business services (file servers, mailserver etc.), know that a hypervisor and the necessary utilities require some RAM space, processing power and disk space. In case of ESXi, the free hypervisor, you need about 300MB of RAM to run the hypervisor. Normally the hypervisor absorbs few processor cycles, but network intensive applications can increase the load of the hypervisor significantly. In some cases a complete core can be kept busy doing nothing else than sorting and processing incoming ethernet packets to several VMs.

And the more similar virtual machines you run on top of a single host, the better it gets from an efficiency and cost point of view. For example ESXi uses transparant page sharing, so identical memory pages are shared among several VMs. So several ubuntu servers with the same kernel will use less memory if they are all running on the same physical host.

A dualcore is the absolute minimum for virtualized servers, even home servers. So I would definitely prefer a quadcore or hexacore system for a home server. Of course, the CPU is just one component. Make sure you can have enough RAM slots and at least two gigabit ports.

Question #2 by Dennis H.

What is in store for desktop virtualization? How will virtualization impact cloud computing from a user/customer standpoint? How will virtualization impact home users?

Answer #2 by Rich Brunner, VMware Chief Platform Architect

Desktop virtualization could be most commonly characterized as in the ‘early adopter’ stage despite its massive potential. Often times when discussing cloud computing, the subject equates the technology and benefits to the datacenter. VMware firmly believes that a consistent architecture that supports desktop delivery via the cloud is an important part of the overall enterprise service delivery strategy. From an IT perspective, control is managed through desktop/data leveraging a common cloud architecture, the desktops and data being secure in the datacenter, management being centralized, and cost reductions achieved through pooling, automation, improved service levels and availability. Enterprise end users, on the other hand, seek instant delivery of their desktop, anytime, anywhere, from any device with the rich experience tier to end user identity, not devices.

Question #3 by Ron K.

How do you plan for consolidation when many of the nodes to be consolidated have issues like CPU loops and or nonsensical consumption, like resource intense screen savers?

Answer #3 by Rich Uhlig, Intel Fellow

CPU loops can arise out of different situations, including idle loops and spin locks. When a guest OS enters an idle state, it will typically also issue an instruction like HLT (halt), or issue commands to the CPU to enter a more power efficient state (called “C states”). A hypervisor can set various VT execution controls to cause a VM exit from the guest OS and gain control on such events, and then schedule another VM to run so that the physical CPU resource won’t be wasted.

Detecting idle activity in this way, is more or less standard CPU resource management by a hypervisor, but a more interesting case that of spin locks, where the CPU repeatedly cycles through a loop to check on the availability of lock that might be temporarily held by another CPU. In an non-virtualized system, spin locks usually resolve quickly, because the lock-holding CPU will typically release its lock after a short time, and the lock-requesting CPU will obtain the lock and drop out of the spin-lock loop. However, in a virtualized system, an adverse situation known as “lock-holder preemption” can occur. In this case, the lock-holding CPU – which is now running in a VM – might not be scheduled to run by the hypervisor (i.e., it is preempted), and the virtual CPU requesting the lock will just continue to spin, waiting on a lock that can’t be released until the lock-holder is again scheduled to run. In the worst case, the lock-requesting CPU might spin in a loop for its entire execution quantum, a clear waste of CPU resource. The difficulty here is that the hypervisor doesn’t necessarily know that lock-holder preemption is happening.

To help address this scenario, we recently added a new execution control to VT that has the physical CPU monitor execution within a VM. When an excessive number of iterations around a spin lock are detected (signaled by the occurrence of many executions of the “PAUSE” instruction – a good indicator of a spin lock), the CPU causes a VM exit to return control to the hypervisor so that it can schedule another virtual CPU to run. We’ve found that this new execution control – called “PAUSE-loop Exiting” – is effective in heavy OS consolidation scenarios where the likelihood of lock-holder preemption increases as physical CPUs are oversubscribed relative to virtual CPUs.

For things like resource intensive screen savers, there’s not much that the hypervisor or hardware can do, since the computation going on in a screen saver may be legitimate and what the user desires. The best practice here is simply not to enable such screen savers in guest OSes if their computation is thought not to be useful.