VMFS

Once again, there’s no wireless signal in the breakout session, so I’ll have to publish this in a delayed fashion. Ugh! Someone needs to work on this wireless network.

This is session TA2668, VMware ESX Architectural Directions. This is another session that provides forward-looking information at future versions of VMware ESX.

The presenter started out the presentation by giving an overview of VMware ESX, what it’s designed to do, what features it has currently, what it’s capable of doing, what it knows, how it manages CPU scheduling and other resources like memory. This would include stuff like being aware of the difference between sockets, cores, and hyperthreads; and stuff like VMware ESX’s advanced memory management functionality (like transparent, content-based page sharing). He also reviewed the management of I/O such as network and storage I/O.

Moving into “future features,” these features will focus on security, scalability, interoperability, and performance.

In the security area, VMware is focusing on improving security in a number of areas. One of these is reducing the size of the platform, such as in ESXi; it is anticipated that this will reduce the surface area and lower the number of potential vulnerabilities. VMware is also looking at the use of ASLR (Address Space Layout Randomization) and NX support (No eXecute). Together these features will protect both applications and the kernel and make exploits much more difficult and more difficult to automate and repeat.

In addition, VMware is working on the VMsafe APIs, previously announced at VMworld Europe 2008 in February. These APIs will allow VM introspection and intervention. Security modules will run outside the guest and are strongly isolated from the guest(s) they are monitoring. However, these modules will still have full access, full visibility, and full introspection and control functionality.

On the scalability front, VMkernel will move to 64-bit. Although in practice this will be unnoticeable, it will simplify VMkernel on large memory machines and on systems with larger numbers of CPUs. This will not impact support for 32-bit and 64-bit guests running on VMware ESX. This change will enable support for up to 64 logical processors, up to 512GB of RAM, up to 512 vCPUs per host, and higher VM limits (8 vCPUs and 256GB of RAM per VM). These higher limits will also help improve support for guests with 2 and 4 vCPUs.

VMware ESX will also leverage dynamic frequency and voltage scaling, which will enable the VMkernel to manage power states for CPUs when load decreases. This will be accomplished via Intel Enhanced SpeedStep and AMD PowerNow.

Power will also be treated as a first-class resource in the VI Client, with tracking and reporting of power utilization.

Another scalability improvement is the Distributed vSwitch (DVS). The DVS is a vSwitch that spans an entire VMware ESX cluster. This brings greatly simplified network configuration across the entire cluster, stateful vSwitches (vSwitches can maintain per-port policies), and plugins. Examples of plugins would include appliance APIs (to create inline filters for per-VM traffic) or switch APIs (to modify the forwarding algorithm).

vStorage Thin Provisioning is another scalability improvement. However, as mentioned in my earlier post on BC2621, this may conflict with VMware FT. This is intended to reduce disk space utilization, improve disk-related operations like backup, cloning, etc. Obviously, new alerts need to be created to manage disk allocation and overprovisioning.

Moving ahead to interoperability, the presenter first discussed Enhanced VMotion Compatibility (EVC). The idea behind EVC is masking certain CPU features so that guests can migrate live via VMotion between hosts with dissimilar CPUs. EVC leverages functionality built into modern processors from AMD and Intel CPUs to hide CPU features so that CPUs appear to be identical to guests. EVC is available today in VMware ESX 3.5 Update 2. EVC problems are detected when a host is added to a cluster, to prevent problems before a user attempts a VMotion between hosts with incompatible CPUs.

The Service Console will be updated to a 64-bit distribution running on version 2.6 of the Linux kernel. All hardware device drivers will be in VMkernel; none of them will be in the COS. In fact, the COS filesystem will reside in a VMDK on a VMFS and uses the same storage path(s) as VMkernel. Of course, there is no Service Console for ESXi. Both ESX and ESXi support CIM-based host management.

Another area of interoperability is with storage plugins, using the VMware Pluggable Storage Architecture (PSA). This will enable partners to write plugins to enhance storage functionality. VMware ESX will ship with a plugin known as NMP (Native Multipathing Plugin), which in turn is comprised of SATP (Storage Array Type Plugin) and PSP (Path Selection Plugin). ALUA support will be added as well.

VMDirectPath I/O is another interoperability advancement. This allows the guest to directly control physical hardware. This seems to fly directly in the face of virtualization, which is intended to virtualize and abstract physical hardware away from the virtual machines. However, this could be useful in some instances. Hardware I/O memory management is required in order to isolation guest memory access and translate guest addresses to host addresses. In addition, PCI device reset capability is required.

VMDirectPath I/O does introduce its own set of challenges, such as the impact on VM suspend, checkpoint, and migration. VM memory management is also impacted. It is anticipated that the “Gen1″ release of this functionality will accept these limitations and “Gen2″ will begin to address them.

VMware will also support newer device drivers from partners and will also allow asynchronous device driver updates. A device driver development kit will be available to allow 3rd party developers to add device drivers to VMware ESX. Of course, with the switch to a 64-bit architecture, the drivers will also switch to 64-bit drivers.

Finally, in the area of performance, VMware will improve CPU efficiency for I/O virtualization. This covers an enormous amount of work for reducing overhead, enabling large packet send/receive, scheduling processor interrupts, and the paravirtualized SCSI device to improve SCSI performance. Future versions of ESX are also expected to include large page support. Other areas of improvement include expanded support for hardware virtualization, and VMware will focus on specific application areas to help drive performance and optimization of those applications on VMware ESX. This is in addition to helping customers optimize VMware ESX itself.

At this point, the presenter concluded the session.

Welcome to another installation of Virtualization Short Takes!

• For you Quicksilver lovers out there that also run VMware Fusion, here’s a handy trick to allow you to launch Windows apps to run under Fusion via Quicksilver.
• Duncan of Yellow Bricks points out this VMware Communities Forums thread discussing how to determine which host has a lock on a LUN. This thread also makes brief mention of the new VMFS version, version 3.31, that was released with ESX 3.5, which does a better job of handling SCSI reservations than previous versions. Good find, Duncan!
• Speaking of the new VMFS version, a summary of the information shared in the VMware Communities Forums threads can be found here.
• While we are on a bit of a storage kick, VMware has launched a new VMware Storage blog, and one of the early posts deals with VMFS. The post primarily attacks the notion of VMFS as a “proprietary” file system (which it is) by describing the advantages that VMFS provides. I’m hoping that the new storage blog will get more technical than marketing in the future, but the information is useful nevertheless.
• This link falls more into the “ironic” category than anything else. Do you suppose he got into trouble with Citrix for blogging about how to use a competitor’s product to test ICA performance?
• John Howard gives us an in-depth look at Hyper-V’s handling of virtual NICs in this article. This is particularly important for users who are interested in cloning VMs hosted on Hyper-V; I would assume that SCVMM 2008 will handle this correctly.
• This news emerged several weeks ago via VMblog.com. It’s good to see Leostream getting some recognition; their broker is actually quite good in many respects.
• Sven over at Virtualfuture.info recently blogged about XenServer’s HA functionality and how Marathon’s EverRun products play into that functionality. I actually had a conference call with the folks from Marathon several months ago about EverRun, but never got around to blogging about it. I do like the fact that you can control HA functionality on a per-VM basis, whereas VMware HA is applied to all VMs. (Well, I suppose you could disable HA for the VMs that you don’t want restarted, but it’s not quite the same.) I do agree with both Sven and PeterB’s comments regarding “Continuous Availability”; the sooner that VMware gets this functionality out the door, the more of a leg up they’ll have on the competition.
• As has been reported elsewhere as well, Reflex Security has released the Reflex Virtual Security Center (VSC). The full press release is here. Based on what I’ve read thus far, it appears that the idea behind the VSC is to combine the information from multiple instances of their Virtual Security Appliance (VSA) so that users get the “full view” of what’s occurring across the virtual infrastructure. In this regard, it is remarkably similar to Altor Networks’ Virtual Network Security Analyzer (VNSA), which is also designed to provide visibility across the entire virtual infrastructure.

As always, feel free to share other interesting links and news in the comments below. Thank you!

Before I begin the second installation of Virtualization Short Takes, I thought it was interesting to note that Thomas Bishop over at ScaleTheMind.com has adopted a similar strategy. There’s just so much happening that it’s truly impossible to discuss everything in depth. Even so, it’s often helpful to at least provide the readers with the links and some additional thoughts. It seems like this approach may be the best one to use. I’m certainly open to everyone’s thoughts.

So, on to today’s list of virtualization-related links:

• Frane Borozan has launched p2vbackup.com, a site that describes the process for incorporating virtualization into your backup and recovery process. I haven’t had the time to review the site fully yet, but what I’ve seen looks pretty good.
• Either Duncan Epping at Yellow Bricks just has really bad luck, or he has some sort of link into the VMware Knowledge Base so that he knows when new articles are published. If it’s the former, then his misfortune is our good fortune, as he’s pointed out a potential problem with Storage VMotion that can cause the storage migration to fail and the VM will then not power on. The associated VMware KB article is also available.
• Lou Springer has written a paper on estimating workload consolidation and placement without the use of VMware Capacity Planner. Truth be told, there are organizations that cannot, for whatever reason, leverage Capacity Planner. Lou’s document describes some alternative approaches and some ways of mitigating the risks of those alternative approaches.
• Again via Duncan, here’s some good information on recovering VMFS partitions when you’ve forgotten to set “automount disable” on the Windows-based VCB proxy server. It seems like I recall seeing somewhere that automount was disabled by default on the Standard edition of Windows Server 2003, but enabled on Enterprise. Can anyone confirm that? By the way, it looks like Windows Server 2008 will default to automount enabled.
• And while we’re talking about storage, check out this information from Duncan on Dell’s DRAC Virtual Media functionality and its interaction with VMware ESX Server. Anyone seen similar behavior from HP iLO?
• Via VMblog.com, I saw that Catbird had announced their HypervisorShield, which “is the first virtualized security technology that can monitor and control access to the hypervisor network”. OK, sounds nifty, but I have to side with Christofer Hoff on this one. What exactly is Catbird saying here? Are they protecting the Service Console network interface(s), the VMkernel interface(s), the vSwitches, or something else entirely? Personally, I’m going to wait until I can see more information to make a judgment call on this one.

That’s it for this edition. Feel free to submit any thoughts, suggestions, or rants in the comments below. Thanks for reading!

UPDATE: My recollection on the status of automount in Windows Server 2003 was incorrect. It is enabled by default in Standard, and disabled by default in Enterprise. Thanks to the readers to helped set me straight!