First, a caveat. This is not supported. Most of what I am about to talk about is not supported. Feel free to use this information, but do not call Microsoft if it does not work for you.
With that out of the way – this morning I was asked how to get a Windows Server 2008 core installation working on Windows Virtual PC, with integration components. This is possible, and very handy, but is a little tricky to do.
Windows Server 2008 will install onto Windows Virtual PC in a core configuration with no issues. But when you try to install the Integration Components, the installer will fail with the following error message:

The problem is that the installer is trying, and failing, to initialize the sound card driver that is part of the integration components. What you need to do is to disable the sound card in the virtual machine.
You could do this through our handy COM interface, but it is much easier to just go in and hack the virtual machine configuration file. The first thing you will need to do is to turn off the virtual machine (do not hibernate it, you need to turn it off or shut it down). The file you then need to find is the .VMC file for your virtual machine – it will be in the location that you specified when creating the virtual machine:
Open this file in notepad, and locate the section that talks about the sound adapter (it is toward the end):
You need to change the boolean value from “true” to “false” (in the picture above I have already made the necessary change). When you have done this, save the changes to the file, close notepad and start the virtual machine.
Now the Integration Components should install successfully.
Note, when you select to Install Integration Components from the Tools menu, the installer will not start automatically. You will need to manually change to the CD-ROM drive (most likely the E:) and run setup.exe to start the process.
After a reboot you should be able to enable integration features and get integrated mouse and clipboard support.
Cheers,
Ben
At VMworld 2009 attendees were able to purchase the first book ever published by NetApp in the VMworld bookstore. This book was NetApp and VMware vSphere Storage Best Practices. Since then the book has been a huge success. I was very surprised today to learn that since the book's release on August 31st, it has sold nearly 5,000 copies.
To put the sales figures in perspective, we averaging nearly 1,000 copies sold each month!
The book’s current sales rank on lulu.com is 198.
For all interested in the book, I’m happy to announce that the second edition is now available. It’s packed full of net new content; however, I have to save the details as to what’s new as it ties into our February 18th announcement.
If you want a sneak peek you’ll have to head over to lulu.com
I’ve got more book news on the horizon and as soon as I can share the details, your RSS reader will be the first to know.
Continuing with catching up from the topics that I didn't get to post over the past week and a half...
Last week Storage Monkeys announced the results of their Top Storage Vendor Blog poll. NetApp was well represented with three bloggers placing in the top 10. Val placed 5th, Dave 8th, and yours truly finished 6th.
I'm honored to finish in the top 10 ratings of two industry polls each representing two distinctly separate areas of the technology industry.
For those who voted for the three of us, and the rest of the prominent NetApp bloggers like Nick, Alex, Mike, and Brian and team; I thank you for your votes. I've reproduced the final results of the Storage Monkeys poll here, complete with links to each blogs in order to help you add these sites to your RSS reader.
EMC definitely had a stranglehold on the top spots. It looks like the rest of the storage bloggers have their work cut out for 2010.
You might have noted a slight incompatibility between VMware vCenter Lab Manager and one of VMware vSphere’s core features, Storage VMotion, in this earlier post on VMware Lab Manager design considerations by former co-worker Aaron Delp:
Storage VMotion and VMware VCB are not supported with Lab Manager.
Obviously, this could present a problem for users who might need to migrate Lab Manager datastores from one LUN or array to another LUN or array. So what’s a user to do?
Fortunately, an internal discussion on this earlier today turned up some great information on a utility called SSMove. What is SSMove?
SSMove is a utility installed on the Lab Manager server that allows you to move data from one datastore to another. You can move a specific tree of related virtual machines. See “Viewing Virtual Machine Datastore Directories” in the Lab Manager User’s Guide for more information on trees. To move an entire datastore, you must move all its trees individually.
Credit goes to rockstar team member Denis Guyadeen for pointing out this utility. More information is available at this links:
VMware KB: Moving a datastore using SSMove
VMware KB: SSMove does not work if a datastore is disabled (3.0.2 only)
VMware Lab Manager 3 Online Library - Managing Datastores
So, if you are needing to migrate data in Lab Manager from one datastore to another, this is your tool.
I haven’t yet found any information on whether SSMove is also included in Lab Manager 4. (To be fair, I haven’t really searched too hard.) If anyone knows, please speak up in the comments.
This article was originally posted on blog.scottlowe.org. Visit the site for more information on virtualization, servers, storage, and other enterprise technologies.
Moving Lab Manager Datastores
I know, I know, these days the title is suppose to be the opposite but it seems to me either some folks simply don't get it, or they just underestimate the intelligence, the good judgement and common sense of their prospects.
After two years on a Benchmarking hiatus, EMC have a emerged, seemingly, with a SPECSFS 2008 "winner" clearly looking for leadership and validation. Is there a problem with that? Not at all. In fact, it's common practice in the industry.
Where problems start to arise is when some of the configurations posted produce Benchmark results for which no customer would pay for given the associated acquisition costs of the solution relative to their performing capability.
Case in point...EMC
On January 27th, 2010, EMC, posted SPECSFS2008 results using the following configuration.
EMC Celerra NS-G8
Celerra NS-G8 with 3x data movers and one Control Station (two active data movers and one standby)
Symmetrix V-Max
Symmetrix V-Max with 4x V-Engines, 96 x 400 GB SSD drives, and 4 x 450 GB FC drives
RAID 1 Config: 96 x 400GB EFD divided into 48 2-disk RAID 1 pairs, exported as 192 Logical Volumes. Total Raw Capacity: ~ 38.4TB - Total Usable: 18.8TB
RAID 1 Config: 2 x 2-450GB FC disks in RAID 1 pars exported as 8 Logical Volumes reserved for Celerra system use.
Total Cache: 264GB
FC Switch
24-port switch
Usable Capacity: 48%
The above solution according to the benchmark produced:
· CIFS: 118,463 OPs with 1.92 msec ORT (Overall Response Time)
· NFS: 110,621 OPs with 2.32 msec ORT
Several Points:
1) What's the cost of the solution relative to the results it produced?
By all indications and based on folks familiar with EMC's pricing, the List Price is well over 4-5mil USD
2) Is this solution supported?
Why do I ask this? The reason I ask this, is because, the Symmetrix V-MAX Product Guide, A02, November 2009, states the configuration guideline on the 4 Engine V-MAX to be a minimum of 480 drives. Clearly there are no 480 drives here.
3) The usable capacity of the solution is 48%
To me the results are low based on the cost. Quite low, in fact. There's a Grand Total of 264GB of cache in play here. Each Datamover has 4GB x 2 Running instances. That's 8GB. Then each V-Max engine has 64GB x 4 instances. On top of that, there are 96 EFD and on top of that's there's RAID 1. But despite all that, you can only produce these numbers? In fact, one can claim that the EFDs serve as non-volatile caching mechanism as well. When you start adding up the numbers you end up with TBs of cache and the results then seem even more lousy.
We benchmarked 120k NFS Ops on a FAS6080, with lower response time and with that config we didn't even use PAM Cards. Straight up disk configuration, 336 disks. Furthermore, our config has a cost of no more than 20% (list) as compared to the EMC published one. Oh, and a 67% usable capacity vs 48%.
EMC's config does not do anything other than raise questions regarding their cost/performance of their NAS solution. Since it's true that EFDs are much faster than spinning disks, then the issue must be elsewhere because from EMC's config as compared to the NetApp published results using spinning disks it does not appear that EFD's provide 10x performance advantage EMC claims vs disk. 96 EFDs vs 336 disks. So either the 10x claims are false or EMC's NAS solution simply can't take advantage of them.
There's also another question...Why would you publish NAS results but avoid publishing SPC results? That sounds strange, a little suspicious and certainly downright pretentious. I don't know, maybe they have more to lose with blocks... That said, you can't, on one hand, claim that benchmark results are irrelevant, as EMC has done regarding the SPC, and on the other hand, publish SPECSFS2008 results and tell us how great you are doing.
.
<o:p></o:p>
<o:p></o:p>
<o:p> </o:p>

Calling all coding hacks!
Back in December, VMware launched the VMware Script-O-Mania contest. The goal of the Script-O-Mania contest is to help our wider community adopt ESXi by providing useful, fun and powerful scripts to manage the ESXi platform. But this isn’t just fun and games – there’s real prizes!
So polish off those scripting skills and get coding. The contest ends on March 15, 2010. You can find full details and submit your entry here.
I had a reader contact me with a couple of questions, one of which I felt warranted a blog post. Paraphrased, the question was this: How do I make IP-based storage work with VMware vSphere on Cisco UCS?
At first glance, you might look at this question and scoff. Remember though, that Cisco UCS does—at this time—have a few limitations that make this a bit more complicated than at first glance. Specifically:
With this in mind, then, how does one connect IP-based storage to a Cisco UCS? In these scenarios, you must have another set of Ethernet switches between the 6100XP fabric interconnects and the target storage array. Further, since the 6100XP fabric interconnects require 10GbE uplinks and do not—at this time—offer any 1GbE uplink functionality, you need to have the right switches between the 6100XP fabric interconnects and the target storage array.
Naturally, the Nexus 5000 fits the bill quite nicely. You can use a pair of Nexus 5000 switches between the UCS 6100XP interconnects and the storage array. Dual-connect the 6100XP interconnects to the Nexus 5000 switches for redundancy and active-active data connections, and dual-connect the target storage array to the Nexus 5000 switches for redundancy and (depending upon the array) active-active data connections. It would look something like this:

From the VMware side of the house, since you’re using 10GbE end-to-end, it’s very unlikely that you’ll need to worry about bandwidth; that eliminates any concerns over multiple VMkernel ports on multiple subnets or using multiple NFS targets so as to be able to use link aggregation. (I’m not entirely sure you could use link aggregation with the 6100XP interconnects anyway. Anyone?) However, since you are talking Cisco UCS you’ll have only two 10GbE connections (unless you’re using the full width blade, which is unlikely). This means you’ll need to pay careful attention to the VMware vSwitch (or dvSwitch, or Nexus 1000V) configuration. In general, the recommendation in this sort of configuration is to place Service Console, VMotion, and IP-based storage traffic on one 10GbE uplink, place virtual machine traffic on the second 10GbE uplink, and use whatever mechanisms are available to preferentially specify which uplink should be used in the course of normal operation. This provides redundancy in the uplinks but some level of separation of traffic.
One quick side note: although I’m talking IP-based storage here, block-based storage fans need to remember that Cisco UCS does not—at this time—support northbound FCoE. That means that although you have FCoE support southbound, and FCoE support in the Nexus 5000, and possibly FCoE support in your storage arrays, you still can’t do end-to-end FCoE with Cisco UCS.
For those readers who are very familiar with Cisco UCS and Nexus, this will seem like a pretty simplistic post. However, we need to keep in mind that there are lots of readers out there who have not had the same level of exposure. Hopefully, this will help provide some guidance and food for thought.
(Of course, one could just buy a Vblock and not have to worry about putting all the pieces together…hey, can’t blame me for trying, right?)
Clarifications, questions, or suggestions are welcome in the comments below. Thanks!
This article was originally posted on blog.scottlowe.org. Visit the site for more information on virtualization, servers, storage, and other enterprise technologies.
Using IP-Based Storage with VMware vSphere on Cisco UCS
I want to tell you a story about how my evening went the other night. I hope you don't mind a narrative.
Monday I received an email from a friend in the VMware community, "Did you see the Register, it's unreal, EMC arrays crushed the SPEC benchmarks!" As you'd assume, this news got my attention. I mean, EMC hasn't published a SPEC benchmark in years.
(The last EMC SPEC submission was published in November of 2007)
Crushed? My buddy said EMC crushed the results! I couldn't stop my mind from racing, had EMC unleashed some new technology which could revolutionize the storage industry? I mean, I thought NetApp had the coolest tech. I mean we are the only ones to offer production dedupe, intelligent caching, and the most integrated vCenter plug-ins. What could EMC have created?
I’m man enough to admit, I began to panic. Maybe it was time to freshen up the old resume and beg Chad for enlistment in his Army. That wouldn’t be such a bad place for me to land. I mean Chad is a great guy, heck I know and respect many of the guys on his team, so I know we'd kick butt together. Now I realize I'd have to take a few lumps from Zilla, but privately we’re friendly, so I think he'll hold back on a few of his punches; however, I'm sure, I mean I’m positive Chuck would beat me with a pillowcase full of oranges. That would be a pretty rough outing, but bruises heal right? I'd get over it.
It was time to get a grip and calm down. I fired up the MacBook, and as Chrome launched I braced myself for the worst.
There is was, right in front of me, EMC had in fact returned to SPEC and published 110,621 and 118,463 IOPs in the NFS and CIFS SPEC SFS2008 and SFS2008_CIFS test beds respectively!
I Needed to Know More, How Was This Possible?
I clicked on the link to read the EMC test bed configuration...
This configuration is clearly, a best in class configuration. I mean, it’s the VMax with EFD; there is no wonder that EMC was able to obtain 110,621 and 118,463 IOPs respectively in the NFS and CIFS benchmarks.
Feeling Like a Kicked Dog...
At this point I'm feeling pretty low. I get up from my desk and head into the kitchen. I steal a few pieces of Ghirardelli chocolate from my wife's stash (the peanut butter and chocolate squares are a nice pick me up when you're feeling blue).
Knowing I will have to face the music, I mean everyone is gonna know about the EMC results, I muster up the courage to peak at the posted NetApp SPEC submission. And there it was, NetApp had published meager results of 60,507 IOPs. Ugh, does it get any worse? 60k? 60k? 60k stinks compared to 110k!
I Needed to Know More, Why Such Low Results?
I clicked on the link to read the NetApp test bed configuration...
I nearly fell out of my chair!
Where's all of the hardware?
I mean, sure the NetApp results were a bit more than half of the EMC results, but the hardware in the test bed fits in 18u of rack space. Heck, the FAS3160 is the middle model in NetApp's mid-tier platform.
And That's When It Came into Perspective...
Are the EMC numbers outstanding? Yes they are.
Relative to the hardware used to obtain the performance results are the EMC numbers impressive? Absolutely not.
Who would purchase EMC's largest SAN array, three NAS gateways, and EFD drives, which run approximately tens times the cost per GB of a 15k FC drive to obtain results less than what is available with two NetApp mid-tier arrays?
I am begging anyone out there who can ballpark the price of the EMC configuration to please post their information in the comments section of this post. I assure you; the cost to purchase the EMC configuration is easily double (if not triple) the cost to acquire two mid-tier FAS3160 arrays.
Obviously, I'm having Some Fun at the Expense of EMC
Chuck, Chad, Mark (aka Zilla), guys what your company put out serves no one's interest but the sales force at EMC. Test results like this one accomplish nothing but to set a false expectation as to what a customer should expect to receive when purchasing this technology.
Take for example, the EMC performance team used the most expensive type of drives (EFD), and threw away half of the storage capacity by enabling RAID-1 purely for the sake of ensuring high performance.
By contrast, two mid-tier NetApp arrays, would not only provide greater performance at a lower acquisition price, the two combined would provide more storage capacity with 300GB FC drives versus the 400GB EFD drives used in your config (21.8 as opposed to 18.8), and this would be possible with less file systems to mount (4 versus 8).
If you want to promote high performance results based on a large amount of hardware, I’d suggest you take a look at the NetApp SPEC submission of 120,011 IOPs. These results were obtained with a single FAS6080 and a fair amount of hardware, primarily 324 15k FC drives and no PAM. This large config beats both of EMC submissions while providing 64.6 TBs of storage (or 344% more) with smaller (300GB) drives. I’ll also wager this test bed costs less than the EMC config.
Shenanigans seems to be the word Chuck uses for discrediting other storage vendors and their enhancements over technologies offered by EMC.
On multiple occasions Chuck has claimed that NetApp technology is "unobtainable" and to meet said claims we would be "breaking the laws of physics".
Maybe it’s tough being the big dog for so long. I mean, how hard is it to admit that you just don't have the storage get up and go you once had? Sorry, there's no little blue pill for what ails you.
Chuck, EFD drives push 6,000 IOPs @ 20 ms latency. 15k FC drive push 220 IOPs @ 20 ms. How can two NetApp mid-tier arrays with 112 slow, 15k drives out-perform the VMax, Celerra, 96 EFD combo? Did we break the laws of physics? Did we trick out the array by configuring it in a non real-world manner?
Give EMC Credit
It was very smart of EMC to diversify their portfolio and invest in becoming a software company. Eventually we're gonna have to become friends and business partners. It is inevitable. I foresee us as long time technology partners, EMC with your VMware subsidiary and NetApp as the storage which VMware runs on!
The Dynamic Data Center Toolkit for Hosters project have just put up the sample code for a Hyper-V ActiveX RDP control, available here:
http://code.msdn.microsoft.com/ddc/Release/ProjectReleases.aspx?ReleaseId=3833
What this allows you to do is to create a Remote Desktop connection directly to the virtual machine (not to the guest operating system) in exactly the same manner as when you are using the Virtual Machine Connection window in the Hyper-V Management Console.
As this is an ActiveX control you can even use it in a web page if you wish to.
Cheers,
Ben
In the current issue of Fortune Magazine, they unveil the '100 Best Companies to Work For' and for 2010 NetApp ranks #7. While I understand this may not be breaking news for some, I would like to share a few thoughts about NetApp and our company's culture.
Prior to joining NetApp I inherited a FAS230 running Data ONTAP 4.2. During my years as a systems administrator and IT consultant, I found that the NetApp storage arrays far exceeded my expectations. It was for this reason alone, that I joined NetApp.
Now I'm in my 10th year at NetApp. I've watched us create the storage appliance market, lead the adoption of Ethernet based storage access, a pioneer the concept of simplifying storage management, and much, much more. With that said, when I joined I had no idea that the NetApp would become recognized as one of the best companies to work for earning the #1 ranking in 2009.
I compiled the list of where NetApp has ranked for each of the eight years which NetApp has made Fortune Magazine's list.
NetApp first cracked Fortune's list in 2003! Back then we were refered to as 'Network Appliance' and had a significantly different logo!
To be included in this list, one that is loaded with truly great companies, is an honor. I'll admit I did notice most in the list are current NetApp customers. Maybe we do business together because we have something in common? I also noticed a number of our technology partners made the list. Maybe we do business together because we also have something in common?
While the number of technology companies to make the list is short, it is interesting to note that of those on the list there are they are alone in representing their market. A single manufacture represents network devices, one for processors, one for storage arrays, etc...
What Makes NetApp Great
NetApp values teams and teamwork; we emphasize honesty with each other, our partners, and customers. We undertsand that there's more than delivering great technology (and the Friday Beer Bashes) that draw people to want to work for us. We have great culture. One built on open and honest dialog between employees, partner, and cusomters. One which emphasizes teams and teamwork, recognizes outstand efforts, and celebrates victories.
Everyone wants to work for a winning team. It makes going to work filled with a sense of purpose, that you may be able to contribute to accomplishing something truly special in your career. That's what is like at NetApp. We are clearly becoming the defacto storage for virtual data centers and this is where the market is growing.
Did you see the news that more than ninety percent of all VMware View (aka virtual desktop) deployments run on NetApp? More than 1,000,000 desktops to date!
We Have A Reputation to Uphold
Did you know that NetApp's culture is so well known around Silicon Valley that the Stanford Graduate School of Business published a case study highlighting it as a foundation of NetApp Leadership? The case study is entitled “NetApp and the Challenge of Global Leadership”
Great Culture is Something You Can't appreciate Unless You've Expreienced It
Several years prior to NetApp I was fortunate enough to spend five years with Marriott International (#84 in 2010). I will attest, once you've worked in a great culutre you will demand it from any future prospective employer.
So I extend an offer to you. Are you interested in joining a perennial all-star work force? One which is helping to revolutionize the virtualization of data centers?
If so, visit our careers portal, we're hiring!
You may have noticed that outside of last week's Cisco NetApp VMware alliance launch I haven’t been writing with much frequency. The reason for the recent lack of posts were due to a misbehaving gallbladder and subsequent Cholecystectomy.
I didn’t realize I had a flaky gallbladder until I had my first attack during the European portion of NetApp’s Insight 2009 Conference, which was held in Athens Greece. I can testify that incurring a medical emergency while traveling internationally sure makes a trip memorable.
With that said, I’m happy to report I’m healthy, back to full speed, and with all of the activity from last week I have a number of posts to get caught up on.
The Windows Server Performance team have done a really interesting post on how to optimize network performance inside of virtual machines by increasing the size of the VMBus buffers used by our network adapters. They also do a very good job of explaining the causes and implications of performance issues around virtual networking – so go check it out:
Cheers,
Ben
I agree that breaking the storage encapsulation in Virtual Machines is generally a bad thing. What do I mean? That the entirety of the Virtual Machine is not contained in VMDKs stored on some datastore. Examples of this are RDMs, iSCSI in guest and NFS mounts in guest.
In general, breaking the encapsulation model is something to do rarely, not frequently. Why? It makes management more complex, makes certain operations impossible (ergo you can’t do a storage vmotion for a device that is mounted via iSCSI in a guest).
But – just like all things – there’s a couple reasons why the purists who say “Never!” should be walked away from… slowly…
Real world example from yesterday. A customer is using Oracle 11g on an NFS datastore and has 1GbE connectivity. For those of you who read the blog post that Vaughn and I wrote here, you immediately see that you will be bound by the bandwidth (MBps) of a single vmnic on the NFS datastore, as the TCP/IP hashing used for link aggregation only applies if you have multiple TCP sessions, and NFSv3 uses only 2 TCP sessions (control and data) per datastore.
So, in the spirit of being a purist, the answer is:
And if you’re SUCH a purist that you would rather throw out the baby with the bath water rather than compromise dramatic principles: dont’ visualize that workload until a future vSphere release that supports NFSv4 or pNFS.
Those are answers, sure, but they aren’t great ones (unless block datastores are operationally simple for the customer). What about the basic option:
“Just mount the NFS export to the guest”.
Are there downsides here? Sure – the ones I listed above, and a few others. But there’s a big upside. the virtual machine network interfaces don’t have the same restriction here that applies to the vmkernel ones used for the NFS datastore. You can drive more TCP sessions, with multiple Virtual Machine interfaces, since you can then basically configure it the same way as a physical host. Perhaps most importantly – you can virtualize that host.
BTW – this isn’t academic – was a real customer use case. Also, reference architectures (either way) have been created (these require a powerlink login to access). See below:
Reference Architecture: EMC Unified Storage for Oracle Database 11g/10g - Enabled by EMC CLARiiON, EMC Celerra, VMware vSphere, and VMware High Availability (HA) using FCP and NFS
This Reference Architecture provides an overview of the architecture of a virtualized solution that uses the EMC Celerra unified storage platform, a CLARiiON CX4 SAN array, and Oracle Database 11g and 10g on Linux over Fibre Channel and NFS. Key elements, physical architecture, and hardware and software resources are among the topics discussed. Date: November 25, 2009 Type: pdf Language: English Size: 0.56 MB Category: Technical / White Papers Intended Use Author: Jeff Browning , Chidambara Shashikiran
Reference Architecture: EMC Business Continuity for Oracle Database 11g - Enabled by EMC Celerra NS-960, VMware vSphere, and VMware High Availability (HA) using DNFS and NFS
This Reference Architecture provides an overview of the architecture of a virtualized solution that uses the EMC Celerra unified storage platform and Oracle Database 11g and 10g on Linux. The solution uses either the Oracle Direct NFS (DNFS) protocol (Oracle 11g) or the kernel NFS (KNFS) protocol (Oracle 10g) to access the storage elements for the Oracle database. It is booted on virtualized hardware and incorporates a four-node VMware High Availability cluster. Date: November 25, 2009 Type: pdf Language: English Size: 0.441 MB Category: Technical / White Papers Intended Use Author: Jeff Browning , Chidambara Shashikiran
Long and short – don’t trust purists. Life is full of compromises. Don’t compromise core principles (like “being a VM is generally a good thing”) because of purist issues.
Hi folks! Been a while, but I have a couple nifty tidbits here for you all:
A lot of folks have been having trouble with getting VMware View’s PCoIP to work in higher resolutions. This is caused by your Virtual Machine not having enough VRAM to power higher resolutions (since unlike RDP, PCoIP is using the “physical” video card of your Virtual Machine, as opposed to a virtual video device like RDP). There have been several workarounds:
That last one is obviously ideal, but it’s a pain and a waste of time to go through creating the pool. Even worse, if you made the mistake of building a pool out of the VM already, the View Manager prevents you from using the template VM as the source for an Individual Desktop!
So I wrote this PowerShell function that, when you feed it a VM object, will correctly set the VM to have enough Video RAM and display ports for 2 Monitors, each running at the max resolution of 1920×1200.
function Set-VRamSize ($vms)
{
$vmviews = $vms | Get-View
$vmConfigSpec = New-Object VMware.Vim.VirtualMachineConfigSpec
$line1 = New-Object VMware.Vim.optionvalue
$line1.Key="svga.numDisplays"
$line1.Value="2"
$line2 = New-Object VMware.Vim.optionvalue
$line2.Key="svga.maxWidth"
$line2.Value="3840"
$line3 = New-Object VMware.Vim.optionvalue
$line3.Key="svga.maxHeight"
$line3.Value="2400"
$line4 = New-Object VMware.Vim.optionvalue
$line4.Key="svga.vramSize"
$line4.Value="36864000"
$vmConfigSpec.extraconfig += $line1
$vmConfigSpec.extraconfig += $line2
$vmConfigSpec.extraconfig += $line3
$vmConfigSpec.extraconfig += $line4
$deviceSpec = New-Object VMware.Vim.VirtualDeviceConfigSpec
$videoCard = New-Object VMware.Vim.VirtualMachineVideoCard
$videoCard.numDisplays = 2
$videoCard.videoRamSizeInKB = 36000
$videoCard.Key = 500
$deviceSpec.device += $videoCard
$deviceSpec.operation = "edit"
$vmConfigSpec.deviceChange += $deviceSpec
foreach($vm in $vmviews){
$vm.ReconfigVM($vmConfigSpec)
}
}
The script is also available on my Sky Drive.
In related news, the HP t5545 (along with a slew of other Linux-based Thin Clients) now supports PCoIP using the new client that you can download here.

Today Anton – from the Hyper-V development team – released the Hyper-V VM State to Memory Dump Converter tool.
What this tool does is allow you to take the saved state files from a Hyper-V virtual machine and convert it to the memory dump format that is used by the Windows debugging tools. This is very handy if you are a developer who wants to poke around inside the state of a virtual machine – without generating a full memory dump internally (or configuring and connecting a debugger).
You can even use this tool to look at the memory state from a virtual machine snapshot.
You can download the tool (and read more about it) from here:
http://code.msdn.microsoft.com/vm2dmp
Cheers,
Ben