SSD

Probably the most contentious finding from my initial testing was that disk performance and bus speed aren’t significant factors in most of those results (start-up and shut-down times being a notable exception). To recap a bit of my initial summary:

Disk performance and bus speed did not prove to be significant factors in these results (except for virtual machine start-up times). Obviously there are fundamental differences about SSD (yet untested) that may skew this picture, but I will be surprised to see big differences. If we’ve got these tests right, and they are actually representative of the tasks that slow down development, then we would expect to see wider variance across bus or disk speeds. We don’t.

• This assumes the disk is relatively uncontended. Virtual machine performance degrades in every type of test while large file operations are running concurrently on the same disk. This could be copying an ISO, importing or exporting a virtual machine or any other sustained large file operations.

The obvious follow-on test would be to repeat on the same system with SSD. Unfortunately I’ve not found the time or hardware resources to do that yet, but today I ran an indicative test. In this scenario, I installed two new boots on a brand new Lenovo ThinkPad W520. One drive was an SSD in the second bay, the other was a 7200 RPM SATA drive (I don’t have specs for either to hand, but they were the default Lenovo offerings). For both boots I ran the VMs on the other spindle, so we had one test with an SSD system drive and VMs running on mechanical drive. For the second test I inverted the configuration and had a mechanical system drive with VMs running on SSD. In both cases there was no appreciable system contention outside of these tests.

The results? Identical. First page load after application pool recycle times were around 10 seconds for Central Administration, a blank site and a My Site Host. 16 seconds for a customised intranet solution (the same one from the initial tests). These are very similar times to the desktop results from my original tests – only marginally slower. What does this tell me? I should complete the testing for more scenarios than just the first page load times. But given that it won’t happen any time soon, I’m pretty comfortable assuming that SSD isn’t going to automagic performance improvements where disk speed is otherwise not a factor, and I’m happy standing by my initial analysis with this supplementary finding in hand.

To be crystal clear, I’ve seen first-hand how quickly a VM starts and shuts down when running on SSD. It’s stunning. And there’s clearly a subsequent gain reaching a post-start-up stasis of sorts. I always waited for my system to calm down like this before any testing could begin, and in some cases that might take ten minutes on a 7200 RPM mechanical drive, and even longer over USB2. However, I don’t actually see this as a major productivity loss. Irritating, yes. A sound business case? Probably less so. I imagine doing lots of full crawls would translate to a big productivity gain on SSD, but is that a major issue for most developers on most projects? Not consistently so, in my experience. But if you’re developing a FAST solution it would probably be a good idea. Maybe even isolate all of the DBs on the SSD. There would certainly be scope to play with this once you have known disk contention that you’re fighting.

The problem I have is that I can’t find any other scenarios which are as disk-bound as we might assume. When we first started this testing in late 2009, our first inclination was to add eSATA drives on a PCI Express port to get a second spindle. Freeing up the VMs from system activity and large file operations on the system disk is a clear win, but this will be true for any disk of any speed on virtually any bus if my initial test results are to be trusted, which means that the SSD investment for VM performance gains is only likely to get you faster start-up/shutdown times and anything else that involves large file operations.

All this said, if budget and SSD reliability are not concerns, load up on them, assuming it gets you sufficient storage capacity. It won’t hurt, so long as they don’t fail all the time. Additionally, it may be beneficial to get an SSD for the system drive, if other non-development activities would benefit from it. Or it may be that start-up/shutdown times are compelling on their own. In the final analysis, I’m in no way opposed to SSD, but when it’s my neck on the line for justifying hardware purchases, I want concrete, consistently-realised performance gains if I’m going to recommend a less resilient, lower capacity, more expensive technology. In most cases, I’m not sure that’s the case for virtualised SharePoint development.

i5 vs. i7

One of the other key follow-on investigations from last year’s testing was a comparison of i5 vs. i7 processors. I’ll quote the initial context here:

• The benefit of spending on i7 processors is in doubt. We are seeing very minor performance penalties when adding more than two CPUs in both VMWare Workstation and Hyper-V for most tests. There were also very minor improvements for some tasks, but on the whole there does not appear to be a measurable benefit. This might vary if the host OS is doing a great deal with the CPU, but that is liable to cause other contention issues than just in the CPU (on a laptop).
• The only tasks that appeared to use all 8 cores in a SharePoint VM were:
  • Retract/Deploy of a solution (but only very briefly)
  • Create web app, or Create site collection (but at low percentages)
  • Rebuild with Code Analysis (but not fully)

Since the initial testing, I’ve continued to experiment with two versus four cores in the VM, and have never seen a significant enough difference to endorse using more than two, but at the same time, I don’t think the penalties for multiple cores are significant enough to worry about, if any user thinks that four cores will be better. Note: I’m only talking about development here.

Based on these findings, I had a hunch that a faster clock speed i5 would outperform an i7, assuming two or fours cores running inside the SharePoint VM. For the sake of simplicity I’ve tested with two cores. For these follow-on tests I used the same ASUS V6-P7H55E model that I used during the original testing, with an identical spec/configuration and the same VM, with one exception. We replaced the Intel® Core™ i7-870 Processor (8M Cache, 2.93 GHz) with an Intel® Core™ i5-680 Processor (4M Cache, 3.60 GHz) – faster speed, smaller cache.

To my surprise, the performance tests returned virtually identical results to my initial testing (all within the margins that the initial tests deviated). Reviewing those results again, we can see that for most tests disk performance is not an issue (see above), and these tests suggest that CPU is not a bottleneck to further performance gains beyond a certain point (I believe an older CPU would fare poorly against either of these, but if a 4.0 GHz i5 came along, I’m not sure we’d see an improvement over these results). These machines have reasonably high-spec RAM, so memory speed does not seem a likely candidate for further improvements. Based on resource monitoring during testing, I can’t see that anything is maxed out, so I’m beginning to think there’s something inherently languid in the sequence of this computation. Perhaps a deeper dive is in order some day, but I’m probably not the best person to take that on.

As an aside, I can confirm that I’ve been running up to six VMs concurrently on this desktop with the i5 over the last couple of weeks. Starting all of the machines up at once is rough, but after 15-20 minutes it’s handling it no problem, and I don’t have to do that unless I’m taking a major snapshot. This suggests disk starts to become an issue with six VMs running at once, but that shouldn’t surprise anyone. If anything I’m surprised it’s not more of an issue on this machine, and if I continue to need this many VMs at once I’ll probably sacrifice my RAID 1 array for two separate disks. I’d be hesitant to suggest SSD in this case, since six VMs is probably going to chew up more storage than most SSDs will accommodate.

Based on these results and this longer-term experience, I’d recommend the higher-speed i5. I don’t seem to lose anything with the i5, at any rate. Maybe even go down to a 3.0 GHz i5 and save some money? If you know you have a specific scenario that will consistently utilise eight cores, go for the i7. But ultimately, both of these CPUs are fast.

Windows Experience Index and CPU Benchmarks

I’ve had a number of discussions with people about performance since publishing these posts, and it’s surprised me to find how many people actually look at the Windows Experience Index. Unfortunately, in my experience, this really doesn’t tell us much on today’s machines. A poor-to-average developer machine today gets a good score, unless it has a 4200 RPM hard drive (in which case it shouldn’t be used by a developer). Also, graphics performance is probably irrelevant. I really don’t think this index sheds any light on the SharePoint Development Experience Index, as it were.

Along these lines, with the receipt of a few new Sandy Bridge CPUs in these Lenovo laptops, we started running CPU benchmark tools. These are quite useful for diagnosing problems (early BIOS versions on the W520 were slooooooooooooooooooow – make sure to apply v1.25+), but beyond that, I’m not sure they tell us what we need to know for SharePoint development. For instance, at one point we saw hugely different CPU benchmark scores but the SharePoint performance tests were roughly the same. I guess I mention these tools here to say that they may be useful in some cases, but I think these real world tests probably tell us more.

Sandy Bridge

“How good are these Sandy Bridge CPUs”, I hear you mutter? Battery life is amazing. I accidentally left the Lenovo W520 running unplugged all day today. I think it lasted about six hours. Performance-wise, you’ve seen the ~10 second first page load times after an application pool recycle on a few of the standard SharePoint OOTB templates. That’s on a 2.0 GHz Sandy Bridge i7. This is not far off the 2.93 GHz first generation i7 desktop CPU results from our original tests, and much better than the first-generation i7 laptop PCU. Pretty good, I’d say. I can’t wait to see the second generation desktop speeds. Note: the desktop i7 models also have integrated graphics, where the first-generation desktop i7 CPUs did not. Now to hope there aren’t any more recall issues.

A few other things to note:

• Until a few months ago, I didn’t realise that dual-core i7 CPUs exist. I thought they were all quad-core. Not so. This is important because if you find a laptop model with four SODIMM slots (to get you 16GB RAM, and 32GB in due course), the fine print will probably tell you that you will only get two SODIMM slots unless you purchase a quad-core CPU.
  • There’s a secondary “gotcha” here, in that the quad-core laptop i7 CPUs peak at a much lower clock rate than their desktop siblings. I think the fastest first-generation quad-core laptop i7 CPU peaks at just over 2 GHz, and most laptop manufacturers have very few models, if any, with this CPU. In fact, we struggled to find anything other than 1 Lenovo, 1 Dell and 1 HP model at 15″. Most of these only had availability for lower clock speeds and we nearly had to settle for 1.73 GHz. These are all very expensive as well.
• The Sandy Bridge comes to the rescue here insofar as it has higher clock speed quad-core laptop i7 models, even if these are also slower than their desktop siblings. However, it’s also worth noting that in most CPU comparisons of Sandy Bridge to 1st-generation i7 models, the Sandy Bridge annihilates. Basically, at this point, if shopping for a high-performance SharePoint development laptop, you should be looking at Sandy Bridge. They may actually be cheaper as well – somehow.
• Also be aware that the Japanese earthquake has caused severe manufacturing delays for most hardware vendors. You may find you need to settle for a lengthy lead time at the moment.

• SharePoint 2010 Infrastructure for Amazon EC2 Part I: Storage and Provisioning
• SharePoint 2010 Infrastructure for Amazon EC2 Part II: Cloning and Networking
• SharePoint 2010 Infrastructure for Amazon EC2 Part III: Administration, Delegation and Licensing
• SharePoint 2010 Infrastructure for Amazon EC2 Part IV: Cost Analysis

My commentary here assumes some familiarity with these earlier posts. This is new functionality that enables new design options. These options should make SharePoint 2010 on EC2 more appealing for a few specific uses.

VM Import for VMware vCenter

While this first update is quite eye-catching, and will be brilliant for some scenarios, I don’t see it as massively game-changing. I first noticed it in the March 2011 AWS Newsletter, so this is pretty new stuff. I think the blurb speaks for itself:

Amazon EC2 VM Import Adds Connector for VMware vCenter
Amazon EC2 VM Import has released Connector vApp, a virtual appliance that works with VMware vCenter making it easier to import your preexisting virtual machines (VMs) to Amazon EC2. Amazon EC2 customers can use a familiar graphical user interface to select a virtual machine (VM) and specify the AWS Region, Availability Zone, operating system, instance size, security group, and VPC details (if desired) into which the VM should be imported. Once the VM has been imported, you can launch it as an instance from the AWS Management Console. For more information about this feature, see the Amazon EC2 User Guide.

I have yet to put this to the test. There may be big issues with this for all I know, but I figured it was worth spreading the word, as many people seem to be evaluating SharePoint 2010 in the cloud at the moment.

One of the “common uses” listed on the Amazon VM Import page linked above is quite clever I think:

Create a Disaster Recovery Repository for your VM images
Import your on-premise VM images to Amazon EC2 for backup and disaster recovery contingencies. Store the imported images as Elastic Block Store-backed AMIs so they’re ready to launch in Amazon EC2 when you need them. You pay no Amazon EC2 usage charges until you need to launch the instances.

This is probably the most compelling reason to consider this new functionality.

Public Addressing and the Virtual Private Cloud

The next update addresses what I saw as the major problem with Amazon EC2 for SharePoint 2010. Namely, that the Virtual Private Cloud only worked with stretched VPNs to it. There was no public addressing. This is no longer the case, as detailed in another AWS mail-out from a couple of days ago (my bold below):

We are excited to announce greatly expanded functionality of Amazon Virtual Private Cloud (Amazon VPC) that opens up the virtual networking capabilities of Amazon VPC to a much broader set of use cases. Before today, you could provision a private, isolated section of the AWS cloud and launch AWS resources into that VPC that were only accessible via an IPsec Virtual Private Network (VPN) connection to your corporate datacenter. With today’s announcement, you no longer need a VPN or existing infrastructure resources in order to leverage Amazon VPC, but can also connect to your VPC directly through the Internet – you define the virtual network that you wish to use.

With this release, you can now define a virtual network topology in the Amazon VPC that closely resembles a traditional network that you might operate in your own datacenter. You have complete control over the virtual networking environment, including selection of IP address range, creation of subnets, and configuration of route tables and network gateways. You can easily customize the network configuration for Amazon VPC, for example creating a public-facing subnet for web servers that has access to the Internet, and placing backend systems such as databases or application servers in a private-facing subnet with no Internet access.

Amazon VPC enables you to leverage multiple layers of security for access to Amazon EC2 instances, including security groups and network access control lists. Additionally, with the expanded Amazon VPC features, you can:

Divide Amazon VPC’s private IP address range into one or more public or private subnets to facilitate running applications and services in Amazon VPC.

Control inbound and outbound access to and from individual subnets using network access control lists.

Attach an Amazon Elastic IP Address to any Amazon VPC instance so it can be reached directly from the Internet.

Store data in Amazon S3 and set permissions so the data can only be accessed from within Amazon VPC.

For more information on Amazon Virtual Private Cloud, visit aws.amazon.com/vpc.

The earlier design of the VPC (or more precisely, the lack of user-controlled NAT) was the major technical shortfall in the Amazon IaaS offering relative to a traditional datacentre. I haven’t yet looked at this in enough detail, as I’m not actively using EC2, so no doubt there are design nuances that will obtain. Also, the VPC and Elastic IP addresses have associated costs and this will add considerable (likely prohibitive) complexity for the network-untrained. Alternately it may require proper administration, and those associated costs.

For my personal use, I see this as a decisive improvement that will make me reconsider EC2 much more closely for testing cross-farm scenarios, perimeter security, proxies and anything that requires a full infrastructure. While much of this may have been achievable without these VPC changes, it would have been massively complex, more costly and less robust.

17-03-2011 update: as my former colleague Glyn Clough rightly points out in the comments here, I forgot to mention that EC2 also supports Windows Server 2008 R2 now, which is sweet!

15-04-2011 update: Paul Culmsee pointed out today that the VPC is still in Beta, which I’ve somehow managed to forget between December and March. This could mean pricing or other changes before RTM. Also note: Paul pointed out that the VPC does not span availability zones, which could be an issue for global organisations.

• SharePoint Development Productivity and Virtualisation Technologies
• SharePoint 2010 Development Environment Performance Tests

I’ve said my preamble in those posts, so I’ll cut to the chase here.

High-Level Summary of Findings

• Disk performance and bus speed did not prove to be significant factors in these results (except for virtual machine start-up times). Obviously there are fundamental differences about SSD (yet untested) that may skew this picture, but I will be surprised to see big differences. If we’ve got these tests right, and they are actually representative of the tasks that slow down development, then we would expect to see wider variance across bus or disk speeds. We don’t.
  • This assumes the disk is relatively uncontended. Virtual machine performance degrades in every type of test while large file operations are running concurrently on the same disk. This could be copying an ISO, importing or exporting a virtual machine or any other sustained large file operations.
    • At a minimum, this is certainly an argument for running VMs on their own spindle, whether it’s over USB, eSATA or SATA. This may be an area where SSD shines.
  • These disk performance figures can be found towards the bottom of this post. Desktop performance was nearly identical running on USB2 at 5400 RPM versus a RAID0 stripe or a RAID1 array on 7200 RPM disks. Laptop performance was also nearly identical over USB2 5400 RPM versus eSATA 7200 RPM.
• Hyper-V performance has been poor on all laptops with i-Series CPUs. This is more pronounced in some areas than others. Our three-year-old model with a Core 2 Duo actually outperforms the new i7 in some cases. When these results are added to known driver issues with Hyper-V on many newer laptop GPUs, we’re looking at a configuration that’s unfit for SharePoint 2010 development.
• VMWare Workstation outperforms Hyper-V on laptops by significant margins in most areas. The exceptions to this are start-up time and performance during the first 10-30 minutes of use (I believe VMWare is ballooning during this time). After that, VMWare Workstation is faster than Hyper-V in every type of test.
  • As a long-time advocate of Hyper-V despite usability deficiencies, I was probably more surprised by the significance of these differences than anyone. I wrongly assumed that Type-I hypervisors would outperform Type-II in nearly every way. While that may hold true on server class hardware, it doesn’t hold true here. I’m a convert.
• While less pronounced, these same findings hold true on the desktop.
  • Desktop performance is very quick on VMWare Workstation, considerably out-performing even Amazon EC2.
  • We can realise significant productivity gains by moving all users who are primarily office-based to a desktop + VMWare Workstation configuration from laptop + Hyper-V, at a fairly small cost (probably half the cost of EC2 over three years – see my recent posts on EC2 for more information).
  • Desktop performance on Hyper-V, while notably slower than VMWare Workstation, is generally faster than VMWare Workstation on the i7 laptop.
• Laptop performance is significantly improved on our current model with VMWare Workstation. These improvements are also realised on the newer model laptop, but the performance delta between the two physical systems is not so significant that it’s compelling to move to a low speed i7 from a reasonable speed Core 2 Duo.
  • The total times for the “End-to-end site creation to debugging tests” were two and a half minutes faster with VMWare Workstation compared to Hyper-V on the Dell XPS M1330. Moving from Hyper-V to VMWare Workstation for laptop users is now an obvious choice.
  • The benefit of spending on i7 processors is in doubt. We are seeing very minor performance penalties when adding more than two CPUs in both VMWare Workstation and Hyper-V for most tests. There were also very minor improvements for some tasks, but on the whole there does not appear to be a measurable benefit. This might vary if the host OS is doing a great deal with the CPU, but that is liable to cause other contention issues than just in the CPU (on a laptop).
  • The only tasks that appeared to use all 8 cores in a SharePoint VM were:
    • Retract/Deploy of a solution (but only very briefly)
    • Create web app, or Create site collection (but at low percentages)
    • Rebuild with Code Analysis (but not fully)
  • We will be running future tests on i5 processors at higher clock speeds to see how these models perform relative to the 1.6 GHz i7.
• The User Profile Service Connection doubles first page load times after an IISRESET in all test cases. I consider this a full validation of these preliminary findings.

Snapshot of key data

The Data

How to read the data:

• Hardware: the physical laptop or desktop model (or Amazon’s EC2)
• Virtualisation: “Hyper-V” is short-hand for the Hyper-V role in Windows Server 2008 R2. “VMWare 7.1.2″ is short-hand for VMWare Workstation.
• #CPU: the number of physical CPU presented to the guest operating systems. Multiple logical cores were only tested in the 4×2 results below.
• Disk: the physical disk configuration where the virtual hard drives are running.
• RAM: the amount of RAM running inside the SharePoint Server 2010 VM. The Amazon EC2 instances were “large instances” but the domain controller was running locally.
• Test: The tests have been described in more detail in my last post.
• Result 1, 2, 3: Each test was carried out three times. The far-right column, Average Result, is an average of the three.
• The Two “Average Load…” rows are an average per-result of the three rows above them. These are tests built on SharePoint 2010 default site templates, which anyone should be able to replicate.
• The “Total create to debug time” row is a sum of the five rows above it.
• All results are in seconds. In cell G21 below, 524 seconds = 9 minutes and 2 seconds.
• For more information on the tests and the testing methodology, see my last post.

Hyper-V versus VMWare tests, all other things being equal

Dell XPS M1330, running Hyper-V

Dell Studio XPS 1645 laptop, running Hyper-V

ASUS V7-P7H55E desktop, running Hyper-V
Note: these Hyper-V tests were accidentally carried out while the VM was running on a RAID 0 stripe rather than on the System disk, so this is not apples and apples, but later disk tests on VMWare Workstation indicated that this shouldn’t make much of a difference, so I’ve left these results in, with this comment.

Dell XPS M1330, running VMWare Workstation

Dell Studio XPS 1645 laptop, running VMWare Workstation

ASUS V7-P7H55E desktop, running VMWare Workstation

VMWare Workstation i7 tests with 4 or 8 cores

Dell Studio XPS 1645 laptop, running VMWare Workstation with 4 CPU

ASUS V7-P7H55E desktop, running VMWare Workstation with 4 CPU

Dell Studio XPS 1645 laptop, running VMWare Workstation with 4 CPU, 2 Cores Each

ASUS V7-P7H55E desktop, running VMWare Workstation with 4 CPU, 2 Cores Each

Amazon EC2 Results

Notes:

• Times were much slower one day than others. This hasn’t been measured over time, but it’s worth keeping in mind. Other EC2 users reported similar problems on the same day.
• Also note: a couple of rows of test data (245 and 248) have been accidentally deleted, but the results were not unexpected in any way.
• Row 263 has no data because measuring time to desktop with EC2 would be too imprecise. It would normally be available within five minutes from start, for reference.

Disk Tests on VMWare Workstation with two cores

The format of these tests change slightly, as I am grouping all disk permutations for the Dell Studio XPS 1645 together, then moving on to the ASUS V7-P7H55E desktop. I grouped them this way because the tests were fundamentally different for laptops and desktops. I did not get the time to repeat the laptop tests on the Dell XPS M1330.

Dell Studio XPS 1645 laptop with VM running on 5400 RPM USB2

Dell Studio XPS 1645 laptop with VM running on 7200 RPM eSATA

ASUS V7-P7H55E desktop with VM running on 5400 RPM USB2

ASUS V7-P7H55E desktop with VM running on a 2nd set of RAID 0 spindles

ASUS V7-P7H55E desktop with VM running on a 2nd set of RAID 1 spindles

…and with that, I’ll let you draw your own conclusions. Should anyone want to contribute supplementary test data in the comments here, or carry out further tests (perhaps with SSD), I would love to see the results. As I mentioned in the last post, there’s still more testing to do.

Update 08 June 2011:SharePoint 2010 Development Environment Performance: SSD, i5 vs. i7, WEI and Sandy Bridge

The Tests

The 21 tests that we settled on were the result of discussions with a number of the core developers, consultants and architects at Content and Code, plus a few tests that I threw in to confirm/disconfirm some of my suppositions, such as the impact of the User Profile Service Connection on first page load time. All 21 tests were run three times for each permutation of hardware candidate and virtualisation technology. We also tested on Amazon EC2. I will discuss the testing process in more detail in a moment.

These tests have been selected for a few reasons:

• They are tests that anyone can run, including Visual-Studio-allergic types like myself.
• They re-enact real-world productivity loss. All tests needed to be significant on our current system or they were thrown out.
• They needed to account for tasks that impact non-developers as well as people that have their head down in code 40 hours/week.
• They needed to be examples of tests that would stress systems in different ways.

First page load tests
These tests were designed to examine what, if any impact different sets of features, functionality and structure might have on first page load times after the application pool is recycled or IIS is reset (while gathering a large set of data to make comparisons across systems). I also wanted to fully validate my preliminary findings about the User Profile Service Connection.

I ran these tests against NTLM-authenticated web applications with the following root site collections:

• Central Administration
• Blank Site
• MySite
• Blank Site, with no User Profile Service Connection
• The Content and Code website solution (structure, without content)
• A custom intranet solution (structure, without content)

All of these first page load tests were repeated for application pool recycles and IIS resets.

End-to-end site creation to debugging tests
I hope these tests are fairly self-explanatory. I used the Content and Code website solution because it’s a public site that people can examine if they want to understand more about the structure of the solution and the scope of customisation tested here.

1. Create new NTLM-authenticated web application from the GUI
2. Create new Publishing Portal Site Collection from the GUI, at the root of the new web application
3. Deploy Content and Code website solution from Visual Studio
4. Delete the publishing site collection (this was a necessary step, but not a test that I timed)
5. Create Content and Code website (structure, without content) from the GUI
6. Debug Content and Code website solution in Visual Studio

Core development tests
These tests were added to account for pure development activity for large projects with lots of dependencies. We turned Code Analysis on for the first test because this is a feature that’s very useful but taxes systems pretty heavily. The code deployment times were all fairly small relative to other tests here, but we need to keep in mind that this could be repeated literally hundreds of times per-day. Note: full deployment is accounted for above in the end-to-end test.

• Rebuild Large Project w/Code Analysis
• Deploy Large Project to GAC/BIN

Disk/IO tests
These tests were thrown in because they have an impact on productivity even if they aren’t particularly routine. For the first test I measured the time from turning on the VM until the desktop rendered after logging on. The second test doesn’t really meet the “real world” criteria I name above, but it is a task that can be a productivity barrier in some cases.

• Time to desktop
• Run full crawl (three web apps, no content)

The Testing

The testing process was entirely subject to personal fallibility, as I carried these tests out myself using fairly imprecise methods like a browser-based stopwatch running on my host system (I made sure not to time things inside the guest, where time can slip occasionally). I also went to great lengths to carry out these tests when the systems were performing optimally; I would run through all of the tests once before recording the first set of results. I felt this approach was the best way to discount random variance. The test results were largely very consistent, so I believe these efforts paid off. Obviously the down-side to testing in this manner is that real work is not carried out in a vacuum, but I don’t see any other way to come up with repeatable tests aside from measures like these. It’s what works for science, after all.

The Virtualisation Technologies

As I mentioned in my last post, I chose to limit the virtualisation technologies to a single technology from each of the types I described. I had to postpone testing against “local systems” due to time pressures. It was the option that fell off because we are unlikely to ditch virtualisation any time soon. It works well for us.

To reiterate here, the candidate technologies were VMWare Workstation 7.1, the Hyper-V role in Windows Server 2008 R2 and Amazon’ s EC2 IaaS offering (a Red Hat implementation of the Xen hypervisor). Again, there’s background for all of this in my last post.

What About the Server Room?

One thing I haven’t discussed in any detail so far is VDI or Remote Desktop services. I briefly touched on shared development environments, but I’ve not talked about hosted, individualised development environments. The reason we ruled this out is cost. While this would probably be the best-performing option, all other things being equal, the costs associated with providing this level of performance in the server room would be pretty enormous. For our purposes we might have exceeded power, cooling and weight limitations before we considered the costs of new blade centres and SANs. These costs would probably be even greater in the datacentre. In short, the same criticism applies to individualised hosted development environments as to shared environments: redundancy and resilience at this level is overkill given the associated costs. The data is not critical and anything that needs to be backed up can be stored elsewhere (like TFS).

Basically, people opt for VDI or Remote Desktop services because a mass of underutilised desktop systems can be heavily consolidated. These systems are not underutilised.

The Hardware Candidates

Dell XPS M1330
This is our current laptop model, upgraded with a 320GB 7200 RPM local hard drive and 8GB RAM. One of the serious options we’re considering is a laptop refresh, due to the age and fail rate of the graphics cards and motherboards on these models.

Dell Studio XPS 1645
This was the least expensive decent i7 laptop I could find for testing purposes, and a leading candidate as a replacement laptop. With an £833 (ex-VAT) starting price it could be bumped up to 8GB RAM for a little over £100 more via Crucial. It’s a very heavy laptop and the glossy shell does it no favours, picking up fingerprints within seconds of use. However, it comes wth a 1.6 GHz i7 processor, 500GB 7200 RPM disk standard, eSATA port and HDMI. No USB3. Basically, nothing here was an absolute deal-breaker for us if performance was good.

ASUS V6-P7H55E
This is a barebones system with the following configuration/cost (as priced at scan.co.uk):

• ASUS V6-P7H55E barebones System = £121.67
• Intel i7 870 (8M Cache, 2.93 GHz) = £217.57
• 4GB Corsair XMS3 DDR3 PC3-10666 (1333) Dual Channel – 4x£56.59 = £226.36
• 1TB Seagate Barracuda SATA 3Gb/s, 7200rpm, 32MB Cache, 8.5 ms, NCQ – 3x£41.94 = £125.82
• Adaptec 1220SA PCI-E RAID Card = £46.40
• ASUS 512MB GeForce G 210 DDR2 NVIDIA Graphics Card = £27.71
• Total = £768.58 (VAT-inclusive)

This system is configured with three internal 1TB hard drives and 16GB RAM. We needed to purchase the RAID card because the motherboard does not have an on-board RAID controller. The graphics card was necessary because there are no integrated graphics on desktop i7 processors (although there are for some i3 and i5 models). The disk configuration was variable, as this was one of the test scenarios. The assumption going in was that two disks would be configured in a RAID 0 stripe or a RAID 1 array, depending on performance outcomes. We would only stripe the disks if there was an obvious, significant performance gain. The third disk would be attached to the on-board SATA controller. I will discuss the recommended configuration in more detail later. Also note: the graphics card supports two monitors across any two of the three outputs, but not three concurrently. Finally, the ASUS V7-P7H55E is nearly identical in every respect. We went with the V6 based on availability.

Other laptop models
During preliminary testing we looked at the Lenovo W510, the Dell Precision 6500 and the Alienware M17x among others. All of these models were candidates that we never ruled out, but we didn’t have sufficient time with them to run the entire set of tests. However, these models had a reasonably similar configuration to the Dell Studio XPS 1645 and the Hyper-V tests we ran on these systems yielded similar results to our test model.

Other desktop models
Obviously a barebones system won’t appeal to everyone as a business solution, and it took me some time to persuade myself that it might be suitable for these environments. It wasn’t until I actually priced up this model and compared it to the comparable Dell T1500 (+~£600) and HP Z200 (slower than either model, and pricier) that I considered how it might work for us more seriously.

What am I examining, and not examining?

We have an old laptop, a new laptop, a new desktop and the cloud. Excepting the cloud (which is fixed), we’re permuting each of these hardware options with VMWare Workstation and Hyper-V test results. We’re then adding tests to examine the impact of spindle/bus speeds and the impact of adding/removing cores to these VMs. Ultimately, I wanted to quantify the productivity impacts of a change to our hardware and/or virtualisation technology as opposed to a change within our virtualisation technology, insofar as these tests could be decoupled.

I am not examining every virtualisation solution nor every hardware permutation but I do try to account for a number of these variables with these tests. I would love it if people carried out similar tests on their environments to help build knowledge in an area that’s hugely uninspected today. These are some of the other tests that I hope to revisit next year:

• The impact of application pooling on first page load times. Preliminary tests suggested there might be a small impact, but nowhere near as significant as the User Profile Service Connection. This warrants further inspection.
• The performance of “local systems” on this same hardware. As I mention above, these tests had to be de-prioritised, but I feel it would be worth identifying if there are any of these development-specific tasks where some, or all virtual technologies suffer.
• While I am running tests against a number of disk buses and configurations, I did not get the opportunity to test SSD performance. Obviously a lot of people will want to know the impact of SSD on these timings, but unfortunately I won’t have an opportunity to inspect that until early next year at the earliest.
• In some cases we work with deep snapshot trees. I want to gain an understanding of how differencing across ten or more files impacts performance for these tasks.
• Compare performance of a higher-clocked i5 to a lower-clocked i7 at a similar price range and potentially explore over-clocking options.
• Compare slower memory on an otherwise-identical system.
• Run VirtualBox tests on an otherwise-identical system.
• Assess the impact of virtualisation optimisations.

Obviously these tests say nothing about the usability of the system, power costs, mobility and more. For the purposes of this post I’m only concerned with outlining how I tested system performance for these real world tasks. In the next post, at long last, I will share the results.

For clarity, I will quickly state the problem as I see it. SharePoint 2010 system requirements and practitioner mobility requirements are inherently at odds. What guidance exists for this unique problem space tends to regurgitate preferences/allegiances rather than comparing technologies and ratifying assumptions with real-world tests. At best, you get system performance indices for a single laptop model, but these results may vary when any hardware component is changed.

How can virtualisation improve system performance?

It doesn’t. People look to virtualisation to solve other problems. However, SharePoint 2010 performs differently in different virtualisation technologies, and the margins of these differences vary by hardware configuration. By all means, the advantages of virtualisation often make it a desirable choice, but these performance characteristics need to be accounted for, lest system performance losses negate the productivity improvements that virtualisation can introduce.

Why virtualise?

There are a number of advantages to virtual systems over physical systems. Many of these benefits can also be obtained with sufficiently mature systems management technologies and physical systems, but these benefits are often easier, quicker or less costly to implement through virtualisation. Some of the benefits include:

• Provisioning times for new SharePoint environments.
• Standardisation through cloned, network-isolated virtual machines.
• Account for volatility with snapshots.
• Standard builds per-project, to share with team members, reducing project initiation costs.
• Virtual appliances produced by Microsoft and third parties, such as the Information Worker Demo VM.
• Reduced hardware rebuilds by removing development tools and SharePoint from the host.

This list is by no means comprehensive. As I say, many of these benefits can be realised with scripting and/or management tools. This list is only intended to illustrate why it’s a powerful design option.

An overview of virtualisation and related technologies

Some example technologies by type:

• Type I Hypervisors
  • VMWare ESXi
  • Hyper-V
• Type II Hypervisors
  • Oracle VirtualBox
  • VMWare Workstation
• Infrastructure as a Service (IaaS)
  • Amazon EC2
  • Azure VM Role (forthcoming)
• Local Systems
  • Native Boot Windows 7 (virtual hard disk)
  • Citrix XenDesktop (VDI)

Note: Virtual PC was not included because it doesn’t support 64-bit guest operating systems. SharePoint 2010 only runs on 64-bit systems.

Some of the alleged benefits of these approaches:

• Type I Hypervisors
  • Better performance**
  • Good management options/tools
• Type II Hypervisors
  • Host Operating System
  • Easy to use
• Infrastructure as a Service (IaaS)
  • Pay as you go
  • Scalability
• Local Systems
  • Good performance
  • Simple to use

Some of the alleged drawbacks of these approaches:

• Type I Hypervisors
  • No Host Operating System***
  • Driver issues*
  • Complicated
• Type II Hypervisors
  • Historically poor performance**
  • Historically, less manageable (snapshots, import/export, etc)
• Infrastructure as a Service (IaaS)
  • Requires stable connectivity
  • Complicated
  • Pay-As-You-Go requires diligence
• Local Systems
  • Easy to damage
  • Slow to rebuild

*Hyper-V has driver issues on some newer laptops. These are most noticeable with graphics, although I have seen audio driver problems as well. Some of these driver issues may be fixed or alleviated in the SP1 Beta/RC for Windows Server 2008 R2.

**This performance bias is one of the things I will be examining in more detail in later posts.

***This is only “sort of” true for Hyper-V, which invokes a “parent partition”. This is a special type of virtual machine that fulfils a similar role to a host operating system, and is often referred to as such.

Why are “Local Systems” included?

I’ve lumped these in for two reasons. 1) They share some characteristics with the other virtualisation technologies, like running from virtual hard drives. 2) By virtue of being local systems, they fundamentally negate some of the benefits that are obtained through virtualisation. Cloning these machines is not an option if SharePoint is installed and configured. It will be necessary to invest in scripting environment provision in order to retain those productivity benefits. It happens that many people choose to take this scripting approach, but it’s worth pointing out that network isolation and cloning can achieve similar results through virtualisation, and this does not obtain with Local Systems.

What about shared, hosted development environments?

In this scenario I’m thinking of hosted development farms, where some or all members of a team use a single environment. Based on my subjective reading of the community, this option seems to be fading away. I think there are three reasons why.

1. Cost. Running development environments on proper infrastructure is expensive. Most components have been made redundant, the storage will be expensive if it performs well, the power/cooling costs are considerably more expensive than for laptops/desktops and you will need to pay people to manage the systems. Even when these costs are split across multiple developers, it’s still expensive unless resources are overcommitted, which negates productivity gains. It also tends to be more expensive to provision new environments and this process can often be an obstacle to business agility. In a nutshell, these are protections that are unnecessary for development environments. Redundancy and resilience at this level is overkill given the associated costs. The most important assets, such as code, standard images and project-specific builds can be protected separately.
2. Hive pollution. If these farms will support multiple projects, as they often do per the previous comments about provisioning, then these systems will inherently differ from the test/stage/UAT/production systems they should resemble. Core files in the hive can be altered from project-to-project, resulting in unexpected behaviour when moving code between these environments. This can seriously complicate troubleshooting and should be avoided.
3. Mobility. These farms aren’t terribly useful to people who are travelling or who are working on-site with restricted outbound connectivity.

All of this said, there are times when project-specific requirements may make shared farms a good option. It may be sensible to take another look for:

• Integration projects.
• Developing with large amounts of data.
• Projects with heavy infrastructure requirements, such as FAST.
  • Perhaps individual development environments can consume a shared FAST Service Application?

Generally speaking, I believe these resources should be provided only in these niche cases.

How is this different from IaaS?

The main differences are costs and capital. Cloud-based infrastructure services are fundamentally just virtualised hosting on an enormous scale. This scale lowers costs to a point where it may be affordable to deploy individual machines per-developer. Although in my analyses I found that IaaS would be more expensive than desktop workstations over three years, this still may be compelling when cash flow issues preclude significant one-time investment or credit flows are restricted. IaaS should also be kept in mind when specific projects require significant provisioning or investment for a short term, for instance testing in a large farm.

While providing a single cloud-based VM per-user solves the first two issues with shared development environments, mobility is still an issue. In many places, stable mobile broadband is flaky at best. Additionally, there are key architectural differences that need to be accounted for when working in the cloud, and on a Pay-As-You-Go basis. I address all of this in my series on SharePoint 2010 Infrastructure for Amazon EC2.

Which approach is best?

This is a high-level overview of the design constraints that limited my choices, before I plunged into a concrete performance review of the remaining technologies.

Local Systems
In my view, Local Systems are only a better choice if the supporting IT systems and processes are very mature and the performance benefits are clear and significant. For most development scenarios, that has yet to be proven. I’ve postponed this virtual to physical performance comparison for now, as the other benefits of virtualisation have ruled this approach out for us, but I hope to revisit it in the new year.

IaaS
IaaS has two key planning considerations. The first is fairly obvious. Outbound RDP Connectivity needs to be open whenever the systems are needed. I encourage people to consider this in some detail and pilot with many types of users before diving in. The second consideration is Pay-As-You-Go. While cloud providers often have an always-on option, it’s usually pretty pricey. The alternative is to find a mechanism to limit compute usage to when it is truly being used, without introducing usability problems. Management tools or scripting may be able to answer these problems, but no one should enter in to this process thinking it will be easy. This is not an easy option. For a more detailed consideration of these issues, refer to my series on EC2.

Type II Hypervisors
VMWare Workstation is the most mature desktop virtualisation product on the market, although in recent years VirtualBox has been gaining share. Choosing between these technologies for my tests was never going to be easy, but I reduced it to a few factors:

• I’ve never met a VirtualBox user that would complain about using VMWare but I can’t say that proposition is reversible. There are a lot of SharePoint practitioners with a strong preference for VMWare.
• VMWare Workstation has native interoperability with other VMWare assets. While VirtualBox supports the VMDK file format, it’s not quite the same thing.
• Both products are fairly inexpensive in the grand scheme of things.
• I had stability issues with VirtualBox circa version 3.14 that left a bad taste in my mouth.

Perhaps most importantly, I felt that the performance comparison of VMWare Workstation to Hyper-V would be the most valuable decision-making information.

Type I Hypervisors
Most Type I Hypervisors would not be suitable for desktop virtualisation because they don’t have a host operating system. While it would be possible to boot a guest OS and remote in to other Virtual Machines over internal networks, this is a complicated approach and the networking requirements would be enough to put off most developers. However, as mentioned above, Hyper-V is a notable pseudo-exception to this with its parent partition.

We’ve been using the Hyper-V role in Windows Server 2008 R2 for development for a little over a year now. While we have successfully capitalised on many of the productivity benefits of virtualisation through this approach, there are a few issues that have never been entirely satisfactory:

• Despite having the host OS, using Hyper-V is still complicated for non-Systems people – particularly the networking.
  • Work-around solutions for Wireless networking are fiddly.
  • Lack of self-contained NAT requires the use of Internet Connection Sharing in order to achieve network isolation, which some users struggle with.
• Lack of Sleep/Hibernate is painful for many users.
• Graphics performance is poor – particularly with large PowerPoint/Visio files, large images and video.
• Audio can also suffer during large file operations.
• Hyper-V is not ready for laptop power schemes.

Despite these niggles, we’ve continued to use Hyper-V while waiting for the forthcoming graphics/memory improvements in Windows Server 2008 R2 SP1. I would class these usability problems as significant inconveniences that sometimes manifest themselves in lost productivity – particularly with new users learning our approach.

New Problems in SharePoint 2010

Since we properly immersed ourselves in SharePoint 2010 development, negative reports about performance started to roll in. These proved hard to validate until a few months ago when my colleagues showed me first page load times after an IISRESET in excess of one minute. This was concrete and repeatable. The problem was more severe on some systems than others, but it was clearly a problem.

The performance tests I’ve been conducting have been an effort to pick apart these results in Hyper-V. Was this new in SharePoint 2010 or did it amplify something that was minor before? Do we get the same problems on different virtualisation technologies, in the cloud or is this a symptom of virtualisation itself? In my next post I’ll discuss the environments, the tests and the testing process.

• Microsoft’s approach to Dynamic Memory is fundamentally different than VMWare’s overcommitment, in that VMWare doesn’t trust information about memory usage from within the guest, whereas Microsoft’s implementation is based around an awareness of the amount and type of memory that’s being used at all times.
• Dynamic Memory will work by Adding/Removing memory.
  • Adding memory is enabled through a new synthetic memory driver.
  • Removing memory that’s not being used is done with ballooning.
  • Memory is now assigned with a few new values:
    • Startup memory is the amount of memory assigned to a VM, which is also the minimum memory the VM will consume (default value is 512 MB).
    • Maximum memory limits how much memory a VM can consume.
    • Priority can be assigned to specific VMs in order to make sure that they receive available memory before other lower-priority VMs.
    • A Memory Buffer can be set to reserve memory for specific VMs, for instance if they need extra memory for file caching.
• Hyper-V Manager adds two new columns.
  • Current Memory identifies how much memory the VM is consuming.
  • Memory Availability identifies the difference between how much memory a VM has vs. wants in a +/-% figure.
    • When the availability goes negative, the Windows guest will start to work with the lesser amount of memory that’s now available to it (via paging, etc).
    • Negative availability will result in reduced performance, but the systems will continue to function.
• Memory is now reserved for the root partition in a different way, so that dynamic memory won’t bring down the host.
  • This amount can be configured with a new registry key based on how the root partition is being used, for instance if it’s your desktop OS.
• As Dynamic Memory is used more, the chances of spanning NUMA nodes increases (on NUMA systems).
  • He points out that different systems have vastly different Back Channel performance, so the impact of NUMA Spanning can be negligible or drastic.
  • In SP1, NUMA Spanning can be disabled (if desired).
• Dynamic Memory also supports Large Pages, which are likely to become more common with virtualised Exchange/SQL.
  • VMWare cannot overcommit these pages.
• I’ve asked if there are specific processor requirements. I’ll be interested to see how/if this supports processors that don’t have SLAT.

Why we’ve chosen Hyper-V

There are broadly five decisive factors: performance, management features (like snapshots), cost, 64-bit OS support and a full host OS (not just a virtualisation administration console):

• Hyper-V is now in its second iteration and has proved to be one of the best-performing virtualisation technologies on the market. With laptops we need to take advantage of every performance gain that we can find.
• Perhaps most importantly, and most often overlooked, Hyper-V is free if you’re already running Windows Server 2008 or Windows Server 2008 R2as a client OS
  • While I work for a Microsoft Gold Partner and Hyper-V is a key part of Microsoft’s future strategy (full disclosure), I believe that most SharePoint developers will have at least an MSDN subscription and a license for a Windows Server operating system, so I believe this is compelling for most SharePoint development environments
• Hyper-V is one of the few virtualisation technologies that supports 64-bit guest operating systems and within that narrow range of choices, it is one of the few that allows a user to log on to a host machine and control virtual machines within it concurrently
  • For instance, VMware ESXi is also a high-performance Type-1 hypervisor that supports 64-bit operating systems, but there is no host machine other than a virtualisation administration console
    • It also has associated costs (support, management tools, etc) that we would prefer to avoid
  • With Windows Server 2008 R2 and Hyper-V, developers can use client tools within a familiar operating system while accessing virtual development environments at the same time
    • This is also true of VMware Workstation, but it’s a Type-2 hypervisor and will have relatively poor performance
  • We need to have 64-bit OS support for Windows Server 2008 R2 and SharePoint 2010 – both of which do not have 32-bit flavors

Our approach

Workgroup development

By building our virtual machines in a Workgroup, we no longer need to worry about SharePoint installation/(re)configuration difficulties, as we will import the same identical virtual machine on everyone’s Hyper-V host. This would not be possible if the virtual machine was a member of a centralised domain because the domain controller would receive chatter from many identical machines and everything would quickly start to unravel

Alternately, we could run Active Directory Domain Services within a virtual machine, but this has a performance overhead that is best avoided unless it is absolutely necessary. Additionally, developing on a domain controller is not ideal

While developing in a Workgroup presents challenges for profile imports, these are far from insurmountable when LDAP directories like AD LDS or SQL users can substitute in many scenarios. The only evident need is a scenario where Active Directory Domain Services (more than just user accounts) are required, and that’s certainly not going to be true of enough projects that it should form a part of the base build. To this end, as requirements for Domain Services are identified we will provide new builds, as they are likely to be very project-specific

Networking

Internet Connection Sharing network

In order to isolate identical virtual machines from each other and from network resources, I’ve created a Hyper-V internal network dedicated to receiving Internet Connection Sharing (ICS) from one of the host’s active network connections. This is an internal network like any other Hyper-V internal network – it just so happens that the host’s adapter on this network will be receiving ICS from another of the host’s connected adapters. Any connection can share to the ICS network – even if Hyper-V doesn’t natively support external networks of that type. Depending on the need, we will share to this ICS network from:

• Hyper-V host external connections (by default)
• Wireless
• Mobile broadband
• VPN

ICS also introduces a layer of NAT between the guests and the physical network, preventing inbound connections to guests over these networks. This is desirable as it is how we achieve physical network isolation, and is the reason why we’ve chosen ICS over Bridging. In the ICS Settings we enable outbound RDP, HTTP and HTTPS connections over ICS by default, although it may be useful to enable other common outbound network protocols like FTP and SMTP. Outbound connectivity from our guest virtual machines is primarily used for connecting to TFS over HTTPS.

Internal network

We have also created a Hyper-V Internal network to support “always on” communication between the host machine and the guest virtual machines. Guest virtual machines can also communicate with each other over this network.

We cannot rely solely on the ICS connection. Guest virtual machine IP addresses on the ICS network will change because they receive them via DHCP from the host’s ICS connection. This is just how ICS works. The host’s ICS adapter becomes a gateway on 192.168.137.1. Any Hyper-V guests on that network pick up DHCP from the host and are automatically assigned an address on the 192.168.137.xxx (255.255.255.0) IP range.

As we rely on HOSTS file entries for RDP connections from host to guest and for browsing to guest SharePoint sites from the host, we need fixed, reliable IP routing and name resolution, so we use this second network for that purpose. The hosts and guests have both been built with fixed IP addresses on this range.

Because this is a Hyper-V internal network, there is no risk of network collisions on these IP ranges (which are identical for all users). Internal traffic never leaves the machine.

Project builds

By providing self-contained environments, our technical leads and/or architects can now customise the base builds to create project-specific virtual machines that can be exported to all members of a team, reducing system/configuration inconsistencies. In practice, the build lead/architect will export the final snapshot of the project environment, which all team members will use as a starting point for project development. As the project progresses, updated builds can be released in this same manner.

Clean hosts

Host machines will be cleaned of development tools and data, allowing quick provisioning. Development tools will not need to be reconfigured, as they will reside in virtual machines that can be exported/imported to any host. Guest base build virtual machines will be provided with as much SharePoint configuration as possible in order to make them light on reconfiguration, disposable and re-deployable.

Project resumption

Project-specific exports will reduce the need for storage of multiple virtual machines – as much as possible. We will retain one virtual machine export in public storage per-project. This will reduce the amount of time involved with resurrecting environments after project completion.

Optimisation

Host machines are built on Windows Server 2008 R2, optimised as much as possible and reduced to the lightest weight achievable. The build will broadly include:

• Hyper-V R2
• Microsoft Office applications
• All browsers
• No development tools (these will all live in guest machines)
  • The only exception to this is the Team Foundation Client which TFS administrators manually install. We have not been able to pick domain users from within a Workgroup environment

Content provisioning

By deploying a single project-specific virtual machine, we can bake content in to the project build, ensuring consistency and reducing the overhead associated with re-deploying content.

Improved testing and reduced volatility through the use of snapshots

By using snapshots we are able to test code and configuration changes without volatility. The benefits of this technology include:

• Capturing restore points at milestones in a server build
• Capturing a stable state before attempting volatile configuration changes
• Capturing a stable state before testing code changes
• Creating an initial restore point after importing a virtual machine and re-configuring network adapters (when required) and making other preferential settings
  • This saves re-importing and reconfiguring network adapters if a machine needs to be rolled back to its initial state
• Exporting a virtual machine to capture a problem when trouble occurs
  • An exact instance of a problem can be captured and shipped out for support, without having to re-create the problem in a distinct environment. This will only apply tot self-contained environments, however

Local source code storage on the host machine

Before our pilot started we identified that storing the local copies of source code within changing snapshot states could create problems. At the same time, we found it desirable to put the development tools inside our virtual machines in order to get around remote SharePoint development difficulties and to keep the host build uncluttered. To resolve this conflict, we adopted this approach:

• Created a share on the host machine and granted ownership of that directory to a new user account that is used solely for this purpose
• Created a new user account with the same name and password in the guest virtual machine
• Mapped a drive from the guest to the host’s new share, using the internal network’s IP address and these new credentials
• Launched Visual Studio and downloaded project source code, pointing to the newly mapped drive as the location for the local source
• Created a new Code Group for the mapped drive to enable trust for code execution

These steps are covered in more detail in the build guides that will follow in later posts. This is just an outline of the approach to extracting the local code from the snapshot state, which should be adaptable to other development systems with snapshots. For instance, we’ve found it necessary to download code to a unique location within this directory for each each user, as TFS tracks the network locations that code is checked out to. This is easy to get around, as each user just specifies a unique directory name. If this were insufficient for project requirements, this TFS behaviour could possibly be “fooled” by using NTFS junction points. We’ve not seen a need for this yet, but we’re confident that with this additional option we should be able to store local source code in this manner, and this has been validated by our project experience with Hyper-V to-date.

Summary

These are the high-level design choices that emerged early in the consultancy and research, which have remained largely unchanged to-date. These choices represent one design that has been validated for our needs, which has some shortcomings like any approach. Some of these issues will be covered in the final post in this series.

The information in this post has not covered implementation in any detail, but do not fret. In the next section I will cover the step-by-step build guide for the Hyper-V host laptop.

Then it occurred to me that this must require a fairly massive amount of added power, especially when you account for the monitor envy this would induce in his colleagues. In fact, I think Virtual PC Guy’s monitors probably account for an ice shelf or two singlehandedly.

I’d struggle to justify it myself, especially with that new Windows 7 (and Server 2008 R2) taskbar. I’m particularly enamoured with Ctrl+click in the jump list. The jump list itself has been much discussed, and I reckon it may justify the upgrade to Windows 7 in its own right. This added functionality seals the deal though.

The length of the title of a document (or perhaps just a rubbish name for a document, or multiple versions of a document) sometimes makes it hard to identify a target in the jump list. If you click the taskbar icon for the application (Word, Notepad, Outlook, browser, etc) while holding down Ctrl it will cycle through the instances of that application, bringing each to the fore in turn for a peek. Think of it as ALT+TAB within a jump list. It’s an excellent way to unveil what’s hidden without introducing a requirement for seventeen screens.