blog.scottlowe.org

I got notice of this whitepaper back during Tech-Ed but it’s been sitting in my “blog posts to write when I get time” pile until now. Microsoft has posted a whitepaper (download it here) as well as a blog entry (viewable here) regarding Windows Server 2008’s new power saving functionality.

While some of the functionality is genuinely new and useful—like the monitoring of CPU utilization and throttling of CPU speed accordingly—some of the stuff in the blog entry, at least, isn’t. Including Hyper-V virtualization as a “power saving feature” of Windows Server 2008 is a bit disingenuous, since any server virtualization solution will provide power savings simply from the simple fact of consolidating multiple workloads onto a single server.

If you’re interested in learning more about how Windows Server 2008 attempts to reduce power usage, have a look at these resources.

Sanbolic, whose Melio FS product I discussed a short while ago, announced today the availability of their Kayo file system. The official press release is here in PDF format. Quoting from the press release:

Sanbolic today announced that Windows Server 2008 Hyper-V virtual machines can now be stored on a single shared storage area network (SAN) storage volume using Sanbolic Kayo File System. The virtual machines can then be moved independently between physical host servers using Quick Migration because all host servers have shared access to the virtual machines files. Kayo FS will be price at $299 per host server and sold in a 5 license bundle.

Kayo FS is described as “VMFS for Hyper-V,” providing file level shared access to a shared SAN volume. This is distinguished from Sanbolic’s advanced file system, Melio FS, which provides byte-range locking and can provide concurrent access to application data on a SAN. The use of either Kayo FS or Melio FS resolves a key problem with Hyper-V deployments that want to take advantage of Quick Migration functionality, and that is that each VM would require its own LUN.

The introduction of Kayo FS also removes the key objection to the use of Melio FS for Hyper-V deployments: price. Kayo FS will be priced much lower than Melio FS; this means organizations adopting Hyper-V will be much more likely to swallow the cost of Kayo FS vs. Melio FS.

Yesterday, Brian Madden wrote an interesting editorial about how he thinks that Citrix will drop the Xen hypervisor in favor of Hyper-V, and will essentially “port” XenServer to run on Hyper-V. Keith Ward at Virtualization Review picked up on this in his post titled “The End of Xen?”. Today, Brian posted a follow-up article clarifying that he wasn’t talking about XenServer, but the open source Xen hypervisor.

Architecturally speaking, the commercial XenServer product and the open source Xen hypervisor are inextricably linked to each other. I don’t see how it would even be possible for Citrix to “port” XenServer, which is a Linux dom0/parent partition plus an “enhanced” build of the Xen hypervisor, to run on Windows Server 2008, or even to use Microsoft’s hypervisor. Keith addresses this point in his article:

I’m not sure what Brian’s sources are on that, but I’ve talked to people in the know for both Microsoft and Citrix, and they state that although the two hypervisors interoperate very well, that they are not duplicates, or near duplicates, of each other. They were developed entirely separately, but there is a common perception, in fact, that Hyper-V is based upon Xen. Not true.

It’s probably pertinent to clarify some architectural issues at this point. (Experts and gurus, feel free to correct me if I am wrong.) Both XenServer (and non-commercial Xen implementations) as well as Hyper-V must have the parent partition present in order to function; they cannot function alone. This is because critical functions like networking and storage are routed through the dom0/parent partition. Without dom0 (a Linux instance for XenServer and non-commercial Xen implementations) or the parent partitions (Windows Server 2008 for Hyper-V), the hypervisor has no I/O functionality. This means that Xen is very closely tied to Linux, and Hyper-V is very closely tied to Windows. Making either run with the other would be a monumental task, if it’s even possible. I could be wrong; while these two products share some architectural similarities, they still seem worlds apart to me.

So, in my mind, the idea of Citrix dropping the use of the open source Xen hypervisor—or any commercial variants of the hypervisor—in favor of Hyper-V are so far-fetched so as to be nonexistent.

Now, that’s not to say that Citrix won’t try to provide some enhanced functionality for Hyper-V, such as live migration (what they call XenMotion and what VMware calls VMotion). This is a key feature that is missing from the initial release of Hyper-V. Is this even possible, though? If it is possible, is it worthwhile? Microsoft has already publicly stated on multiple occasions that live migration will come to Hyper-V in a future release. Why spend a great deal of time, money, and development cycles adding functionality that Microsoft is planning on building anyway?

It’s also very possible, even likely, that Citrix will expand their XenDesktop offering to encompass virtual machines hosted on Hyper-V, thus combining their application/desktop delivery expertise with Microsoft’s hypervisor and virtualization management capabilities. Now that’s quite a possibility, in my opinion. This would be just another example of how Citrix has survived over the years by plugging the gaps in Microsoft’s product line, this time offering significant and beneficial desktop virtualization functionality to Hyper-V environments.

Like everyone else in the virtualization world (except for perhaps the folks in Palo Alto, CA), there’s a lot of Hyper-V stuff crossing in front of me.

This time it’s an article on storage options for Hyper-V, written by Jose Barreto. (You’ll recall that I referenced Jose’s clustering article a few days ago.) Out of the wide variety of blogs coming out of Microsoft, Jose’s is one that I have really, truly found informative and helpful. The home page for his blog is here.

Jose also wrote a follow-up article on Hyper-V’s storage options where he discussed booting from iSCSI.

Great work, Jose! Keep it coming.

Today Microsoft released Hyper-V 1.0, their bare-metal hypervisor. I haven’t been able to find much information on the Internet about it yet other than Alessandro’s announcement and this article at Network World; there was nothing on the Microsoft web site about it at the time of this writing.

I’ve covered Hyper-V extensively in the last few weeks due to my Tech-Ed coverage, so I’ll refer readers back to some of the Hyper-V related sessions for more information on Hyper-V architecture, networking, security, or storage:

VIR367: Hyper-V Security and Best Practices
VIR250: Advanced Storage Connectivity for VMs
VIR358: Hyper-V Architecture, Scenarios, and Networking
Significant Networking Problem with Hyper-V
Hyper-V Clustering Scenarios
More on Hyper-V and NIC Teaming

The release of Hyper-V now opens the door for Microsoft’s System Center team to finalize Virtual Machine Manager 2008, which I currently see as a notable competitive advantage over VMware due to VMM’s ability to manage both Hyper-V as well as VI3. There are a number of VMM 2008 posts available with more information also:

VIR253: Microsoft System Center VMM 2008, Part 1 of 2
VIR360: Microsoft System Center VMM 2008, Part 2 of 2
VIR350: System Center VMM Advanced Integration

The next few weeks will be interesting to watch; in particular, I’m interested to see what actions VMware will take to counter this new competitive threat.

UPDATE: Microsoft finally provided some URLs to their announcements:

Microsoft’s Hypervisor Technology Gives Customers Combined Benefits of Windows Server 2008 and Virtualization
It’s here! Windows Server 2008 Hyper-V is available for download…

My original article on Hyper-V’s issues with NIC teaming has gotten a fair amount of attention.

First Keith Ward over at Virtualization Review blogged about this issue. In his initial post, Keith basically pointed out the issue and then asked the readers for feedback: is this really as big of an issue as it seemed? The readers who responded were split; one blasted Hyper-V and the other wasn’t too concerned.

Keith followed that up with another post in which he provides a response from Microsoft regarding this issue:

NIC Teaming is a capability provided by our hardware partners such Intel and Broadcom. Microsoft supports our partners who provide this capability. This is true whether the customer is running Windows, Exchange, SQL, Hyper-V, etc. We’ll have a detailed KB article about this coming out soon.

Keith’s second article was then also picked up by DABCC.

While Microsoft is sticking to the “this is a device driver issue” mantra, I’m not so sure I agree. I can see their position to a point. In Keith’s second post, analyst Chris Wolf brings up storage drivers. This is similar in that Microsoft relies upon the storage vendors to provide device-specific modules (DSMs) that provide the multipathing functionality. So, like with the NIC teaming, Microsoft is pushing the functionality back to the device drivers and vendors who write them.

But that’s as far as this comparison can be taken. Microsoft officially supports storage multipathing; they don’t officially support NIC teaming. (See this KB article or this KB article.) In addition, Microsoft provides an official framework in which the storage vendors can operate: the MPIO framework. There is no such framework for network redundancy. In fact, if such a framework existed then much of the dissatisfaction with Microsoft over this issue would be alleviated, in my opinion.

Instead, there is no framework to provide official NIC redundancy for any Microsoft product running on Windows Server, and Windows itself doesn’t provide that functionality. Users are forced to adopt unsupported means to provide NIC redundancy. Why shouldn’t they be upset?

By the way, since publishing the first article I’ve been contacted by one of the presenters of the VIR358 session during this which issue came to light, but he has not yet been able to provide any additional information. As soon as more information is available, I’ll be sure to let everyone know here.

After my coverage of Tech-Ed 2008, I think a greater number of Microsoft people are reading my blog. One of them, Jose Barreto, sent me an e-mail to notify me about a post he’d written on the various ways in which to implement Windows Server Failover Clustering with Hyper-V. Quoting from his post:

There are many ways to implement Windows Server Failover Clustering with Hyper-V. I could actually find five unique methods to do it. Some of them will actually not give you a fully fault-tolerant solution, but most of them actually make sense in specific scenarios (even if only for demonstrations). In any case, just trying to understand and differentiate them will probably be a good exercise.

It’s a good read, and I recommend reading and reviewing it if you need to brush on up on how to combine clustering and Hyper-V.

Thanks for the heads-up, Jose, and thanks for the well-written article. Keep up the good work!

In UNIX/Linux integration scenarios, it’s useful to know which accounts have been UNIX-enabled, i.e., have had the UID number, NIS domain, login shell, and home directory attributes configured.

It’s certainly very possible to do this with command-line tools such as AdFind or DsQuery, but users may also find it useful to have a saved query available within the Active Directory Users & Computers console for easy reference.

The way to do this is define a custom query using this string:

(objectCategory=Person)(objectClass=User)(uidNumber=*)

If you add just this text and nothing else in the “Find Custom Search” dialog box (the Advanced tab), then the console will automatically add ampersands and additional parentheses to turn it into a “proper” LDAP query that will show you any account that has a UID number configured. Certainly, additional fields like loginShell or unixHomeDirectory could be added as well, but this query will probably be sufficient for most instances.

I started not to publish this, but figured if I couldn’t remember the exact syntax then someone else might not be able to remember the syntax either. This one is as much for me as it is for others.

I have to swallow my pride and admit defeat: the amount of information at Tech-Ed 2008 has overwhelmed me. I’ll be skipping my last session, a session on Server Core, to return back to my resort and prepare to fly home early tomorrow morning. If you were looking for some information on Server Core, I’m sorry to disappoint you!

Yes, yet another System Center VMM session…it’s pretty clear that System Center is a major component of Microsoft’s server virtualization strategy. This session is VIR350, System Center VMM Advanced Integration, so I suppose we will be seeing more PowerShell and more integration with other System Center family members. As with the other liveblogged sessions, I’ll try my best to weed out duplicate content.

The presenter for this session is David Armour, a Senior Program Manager at Microsoft.

(Side note: what exactly is a Program Manager, anyway? Microsoft must have thousands upon thousands of them. I think that every single presenter so far this week has been a Program Manager or a Senior Program Manager.)

The focus of this session will be on how to extend or customize System Center VMM, and most of the information presented here will apply to both VMM 2007 and VMM 2008 (currently in beta). The key technology used in this case is PowerShell, which can be used either against Hyper-V directly or against VMM. VMM, however, vastly simplifies the PowerShell code required to perform a task when compared to doing the same task against Hyper-V directly.

As has been stated elsewhere, VMM is built on PowerShell, and the GUI represents only a subset of all the functionality of the overall feature set available via PowerShell. Note that the self-service web portal is also built on top of PowerShell. David goes on to discuss the various ways in which a client, like the VMM GUI, interacts with the PowerShell layer.

David then moves into a demo of VMM. He walks through the creation of a new VM, and one thing I noticed that I hadn’t seen before was the idea of a “hardware profile.” This is a set of hardware properties like number of CPUs, amount of RAM, number of NICs, etc. This is a nice feature, as it separates common hardware configurations from the OS installation. Typical VM templates combine the hardware configuration and the OS installation together.

In the demo, David shows how the automatically-generated PowerShell script can be easily modified to use a variable and prompt the user for information so that you can create a script that quickly and easily creates a new virtual machine with the name of your choice. That’s fairly handy.

The next few slides described the hierarchical nature of the VMM PowerShell objects, and how the PowerShell Cmdlets always generate a job in VMM. This allows VMM to audit jobs, provide a job history, and store changes invoked by a job. Security can also be applied to a job, so as to enforce ACLs. This also allows long-running jobs to be asynchronously monitored over time via the job.

David recommends using the PowerShell button in VMM; this automatically loads the appropriate snap-in so that all the VMM Cmdlets are available for use. He then launches into a fairly in-depth demo and review of PowerShell, how to interrogate a snap-in to determine its commands, how to sort or filter output to show only the desired results, how to view the details on a particular command, and how to use some simple pipes. He also showed some ways to get more information or help or to view detailed documentation on a command or a command’s parameters.

The next little while was spent walking through a series of scenarios of using PowerShell to perform various tasks. First is a series of tasks to provide a report (or a group of reports) to management. Next David walks through scenarios involving the creation of new VMs, including creating a hardware profile, attaching hardware, and using intelligent placement for the new VM.

Tired of the boring old PowerShell command prompt? David moves into a demo of PowerGUI, a way of turning PowerShell commands into a GUI application. He also demonstrated PowerGadget Creator, which allows one to create a Windows Vista Sidebar Gadget using PowerShell. This would allow users to create tools to display VM or VM host information in the Vista Sidebar. Finally, David shows how to use Visual Studio to extend VMM using PowerShell. Frankly, this level of extensibility and customization is probably beyond most users, but I suppose it’s useful functionality to have nevertheless.

The next topic was….(drum roll please)….PRO! That’s right, another discussion of the integration between VMM and Operations Manager which is built upon PowerShell. Fortunately, David didn’t spend a great deal of time covering PRO yet again (thank you!).

David closed out the session with a quick summary of the material covered and pointed attendees to a few online resources. I found the session reasonably helpful, even if only from the perspective of getting more familiar with the VMM object model so that I can write my own PowerShell scripts.