5 replies to this topic

[osuwildlifer]

Hello folks,

I'm curious as to the reasoning behind a default setting in Hyper-V server. When you initially configure the role, it lists the location of virtual hard disks. The default location it gives you is c:\Users\Public\Documents\Hyper-V\Virtual Hard Disks.

This seems like a slightly weird choice to me. Why did they make that the default location? Does it have to do with shared access to VMs? What benefits does putting them there provide?

TIA

[Dan~]

iirc, it's only like the setting file that gets created in the location you mention, shouldn't be more than 200k?

The actual VHD should be stored elsewhere, or is that what you mean?

[PGHammer]

osuwildlifer, on 23 April 2012 - 11:18, said:

Hello folks,

I'm curious as to the reasoning behind a default setting in Hyper-V server. When you initially configure the role, it lists the location of virtual hard disks. The default location it gives you is c:\Users\Public\Documents\Hyper-V\Virtual Hard Disks.

This seems like a slightly weird choice to me. Why did they make that the default location? Does it have to do with shared access to VMs? What benefits does putting them there provide?

TIA

A *default location* is generally the first place that an operating system (desktop or server) looks for things. It's no different in Hyper-V (or Windows Server 2K12) than in VirtualBox, VMware, Windows 8, or even Windows 7. This can be changed at VM-creation time (example - private VMs that you don't want shared at all); again, like any of the products I outlined above. That particular choice is because the default settings are for shared (public) VMs (hence that default location two levels down in the Public folder).

I've been kicking around Hyper-V in Windows Server 2K12 (formerly Windows 8 Server) because it's not as restrictive as the same feature is in Windows 8 (client) - SLAT is not a requirement, nor is 4 GB of RAM. (While I have 4 GB of RAM on the host, the Q6600 does not support SLAT. Fortunately, i5-2500k *does* support SLAT, so when I finally get the opportunity to finish my build, this issue goes away.)

I have one question regarding client (specifically, Windows XP) support in Hyper-V - how solid is it compared to other virtualization products (especially desktop virtualization)? I create primarily Windows-based VMs for application-level troubleshooting), and right now, I use primarily VirtualBox for this Being able to replace a third-party utility with an included with-the-OS utility sounds mighty attractive!

[osuwildlifer]

Thanks for the replies and info. The Public user folder still seems an odd location for any OS to use as its default location to me, but I can accept it i suppose. I'll probably move the location to the root of C instead for now, until I see a benefit in the default.

As for the performance of Hyper-V vs others in running an XP vm. I think it's rock solid. I've installed and used Hyper-V as a role on 2 different servers with very different hardware, and they both perform(ed) very well when accessing them from the local machine and remote machines as well.

I've also used vmware and virtualbox, and am a lot more familiar with them. But Hyper-V seems very configurable and straightforward.

[PGHammer]

osuwildlifer, on 28 April 2012 - 02:01, said:

Thanks for the replies and info. The Public user folder still seems an odd location for any OS to use as its default location to me, but I can accept it i suppose. I'll probably move the location to the root of C instead for now, until I see a benefit in the default.

As for the performance of Hyper-V vs others in running an XP vm. I think it's rock solid. I've installed and used Hyper-V as a role on 2 different servers with very different hardware, and they both perform(ed) very well when accessing them from the local machine and remote machines as well.

I've also used vmware and virtualbox, and am a lot more familiar with them. But Hyper-V seems very configurable and straightforward.

That it is.

I've created several different types of VMs in Hyper-V, and used different storage locations, and I have found that the default storage location is hierarchy-dependent (where the root partition of the *server* is in the disk hierarchy) - again, this doesn't differ among virtualization products (not even desktop virtualization products); if you look at how any of the virtualization products treat VMs and virtual drives, they tend to stick to "default" locations by default. Fortunately, like it's counterparts in the desktop-virtualization space, Hyper-V Virtual Machine Manager is amazingly flexible on where it *puts* things if you have a use for it - I can't use the default position due to capacity constraints; my Server 2012 HDD is way too small!. Instead, I use the (much larger) Windows 8 drive/partition for my Hyper-V VHDs (though VM configuration is still stored on the server). What I will be planning on (after some hardware upgrades - mostly drives) is to dedicate two 1TB+ drives to VM/VHD storage - in essence creating a VM/VHD pool.

[goatsniffer]

I use Hyper-V (Server 2008 R2) at home and in several client's locations.

When creating VMs you can specify where the VHDs are stored. It is highly recommended to put them on their own storage drives. At home I have tested them on a 2x1.5TB 7200RPM software RAID0 volume and on a 4x2TB 7200RPM hardware RAID5 volume, the hardware RAID5 mounted VMs had significant IO performance. I managed to copy to/from them fully saturating my gigabit LAN. The same VMs on software RAID0 manage about 50MB/s of network transfer.

Once a VM is turned off you can simply move a VHD to a new location and use HYPER-V Management console to tell the VM new location is.

In regards to using HYPER-V for a client OS, one of my clients had a satellite office that they wished to give access to our network... on a limited budget and internet connection. I created Windows 7 VMs for the remote employees and set up basic machines at the remote location that simple ran a RDP connection over VPN. This ran perfectly for about a year until the satellite location was closed.