Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I've been testing native vhd boot on several servers. It seems to be pretty transparent in terms of deployment and with my seat of the pants testing I have not noticed any difference in performance. The main reason that I want to boot vhd is due to their transportablility between different hardware and to hyper-v servers.

the following roles will be installed.

application server
dc <- haven't tested this yet but see no reason why it won't work.

With the above low impact (in terms of performance) roles do you thing booting from VHD is appropriate.


share|improve this question
why the down vote? – tony roth May 25 '10 at 17:41
yes knowing who is a waste of time but why they down voted would be interesting – tony roth May 25 '10 at 21:32
This seems like more of a discussion item, and I'm not sure if it's a question that can be answered. (Looking at the suggestions at ). The title is poorly phrased, and you don't explain what "native vhd boot" is. Use some links, don't assume that everyone who reads this knows what VHD and dfsr are. Perhaps you should try some more relevant tags to direct the question. – Stefan Lasiewski May 25 '10 at 21:39
Agree with you Stefan, this is a poorly constructed question. – Chopper3 May 25 '10 at 21:52
Fishing for opinions is not the same things as asking a question. Even the title makes no sense. This should either be made wiki or be closed. – John Gardeniers May 26 '10 at 2:11

No, no i wouldn't. There is no reason to add even more complexity for no good reason (and Microsoft saying "this is the future" does not qualify as a good reason) Why make life more difficult by adding another layer to the stack with little to no benefit?

share|improve this answer
well the benefits can actually out way the negatives quite nicely so I'll leave it at that. Yes complexity kills so that worth noting, but I'm not sure yet if its more complex. – tony roth May 25 '10 at 21:58
@tony roth: Can you please point out some good uses for this in production, all I've ever been able to find are as others have said dev/test/demo situations that would be a good fit. And absolutely it is more complex you're adding a visualization layer on top of everything else. – Zypher May 25 '10 at 22:20
there is no "visualization" (just having fun with u) layer. Its a file system just like ntfs is a file system, it just happens to run on top of ntfs. – tony roth May 25 '10 at 22:26
@tony: ok ... lets not call it "visualization" (i can be a good sport - spell check fail) ... lets call it an interpretation layer. You need something to read the vhd container from the file system (ntfs driver) then interpret that output in such a way that the OS thinks it's a disk (vhd driver) and now you need to call you ntfs driver again to read the ntfs file systems inside of the vhd container... if that's not adding complexity to "read file from disk with ntfs driver" i'm not sure what is. – Zypher May 25 '10 at 22:37
@tony: The read from disk and interpret may be the same driver, but that is still a much more complex driver than our trusty old ntfs driver, that does one thing and one thing well. – Zypher May 25 '10 at 22:37

Boot from VHD was never meant to replace traditional image deployment. For best performance you should deploy an image directly to the target hardware. Booting from VHD is meant to allow testing and development in situations where the developer or tester does not have access to virtualization technology (which in this day and age is fairly rare). VHDs should be sysprepped before the first poweron (so offline joins aren't a big help here) so that the system detects the new hardware.

I would certainly not support any applications running on a VHD image rather than the default filesystem. Note that you are dependant on the host filesystem in order to run the VHD. The boot entry "lives" on the parent OS (which also needs to be maintained)

According to this Microsoft Virtualization Team Blog Post One of the goals of native VHD support is to "1.Simplify the experience of creating, managing, and deploying Windows images across both physical and virtual machines using a single image format and common tools. "

This is a great idea in a hyper-v environment where I may have to perform rapid deployment of a machine with unforseen and immediate high cpu or ram requirements. When my virtual machine needs more resources than my hypre-v environment can provide you can use this to rapidly deploy the image to another machine already running server 2008 or windows 7 and repurpose the system. In the case of this question this scenario does not apply, see this link for common VHD usage scenarios. In the case of physical machines the library of images should be maintained in WIM format as it will be more space efficient and be simple to maintain. Should there be a decision to deploy to a VHD, a WIM image can be applied at any time.

There are additional caveats when using VHDS, from the VHD FAQ

Store all critical data outside the native-boot VHDs. When you store critical data outside the VHD that contains the Windows boot image, it is easier to recover the data if the VHD becomes unusable.

Create VHD files with a maximum size that is larger than the minimum disk requirements for the operating system. - note that this means image storage requirements are huge vs a multi instance WIM file

backups are also a concern as you should backup a VHD while it is detached. VSS does support creating snapshots of volumes on a VHD

share|improve this answer
Like I said before MS has stated this will be the future of ms deploys, its already supported with r2's wds server. Have you actually used any of these technologies, like native vhd boot, dism or djoin or are you just speculating on how things work? – tony roth May 25 '10 at 21:31
Do you have any links where MS is pushing this as the future? I'd be interested in reading up on this. Everything I've seen is pushing this for development, demoing, and validation. – Chris S May 25 '10 at 21:52
I'll try to find some links that support this argument, the problem is the email I was sent from MS was probably NDA but since r2 has been released I should be good to go.… is a good start, its old at this point, notice that the discusion around demo,testing and development is just a scenario, nothing more. – tony roth May 25 '10 at 22:15
@Tony, those scenarios are specifically mentioned because they demand very temporary installations of software and rapid redeployment. So using VHDs has a specific benefit to justify the administrative overhead. – Chris S May 26 '10 at 1:29
I'm pretty sure that similar to vmware vmdks, san snapshots are no guarantee of data availability – Jim B May 26 '10 at 18:42

The abstraction does add overhead, particularly if you end up with a fragmented dynamically growing VHD.

If the VHD becomes corrupted, it's more likely you lose the whole thing. If part of a HD becomes corrupted it's less likely you lose the whole thing.

It's an added complication (cost) with no benefit in 99.99% of situations.

share|improve this answer
I've been told by internal MS guys that this will be the way of the future. I'm not concerned with fragmentation since the physical disk would be used exclusively for the boot vhd file. I create the vhd as a fixed disk also. I like the ability to do offline image maintenance, things like add remove features/roles install hotfixes. Even djoin.exe works nicely with vhd files. Thus without even powering up the server I can do 90% of the maintenance work. Also if I san boot these I can use flexclone/mirror as my deployment method. I've tested all of the above and it works nicely.. – tony roth May 25 '10 at 15:26
Now your issues surrounding corruption does make me wonder a little! – tony roth May 25 '10 at 15:29
If the HD is intenal to the machine, you still have to power it up to do image maintenance. All the offline tools like DSIM work on an offline HD (if you say PXE boot); but these are production servers anyway, how often are they offline. Fragmentation still happens unless it's fixed size disk, which you have already considered. If you're SAN booting them, why not just use the disk? Why have double the file system overhead? It's still easy to create an image from the LUN, or to copy it over to another LUN. I don't see much problem with doing this, but I still see almost no benefit. – Chris S May 25 '10 at 17:41
With the patch issue, you can always start a machine to WinPE via PXE (or CD, USB HD, etc) and offline prep the image for the patch; no VHD or WIM files required. But we're still talking about production servers that run 24/7, so they shouldn't be offline in the first place. – Chris S May 25 '10 at 21:53
@tony: I would suggest updating the question with some of the benefits you see from vhd boot. That might go a long way to a better answer from people (for or against you) if what you are really after is a good answer and not just fishing for an answer to backup the ideas you already have. – Zypher May 25 '10 at 22:25

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.