Well we can claim it anyway - the next version of Windows is named... Windows 7 :-)

Read about it on Mike Nash's blog post: Introducing Windows 7.

Watch Chris Slemp's video* for an overview of TN/MSDN's "social platform" that includes:

Social Bookmarking

Community Content (ak.a. "wiki") - for example see http://technet.microsoft.com/en-us/library/cc753637.aspx

Forums - for example, did you know the Scripting Guys have a forum?

Blogs

Code Gallery

Oh yeah, search is now part of the social platform

*Hey, who's profile is that on the screen at about timecode 2:07?

Here's another guest post from Jeremy Hagan, thanks again Jeremy!

If you are planning on using High Availability for Hyper-V there are a number of things to keep in mind while planning your deployment and there are a number of best practices that will impact on your planning.  I will cover the best practices first then discuss how these impact your pre-deployment decision making.

Best Practice 1 – One VM per LUN

High Availability in Hyper-V is provided through WS08 Failover Clustering.  When you fail-over a cluster resource with a dependent disk that disk can only be active on one cluster node at a time.  So if your cluster disk has more than one VM on it, then they must all fail over as a group.  Essentially there is nothing wrong with this, so long as you know what you are doing when you decide to go down this path.  The benefit of one VM per LUN is that you have the best granularity in terms of moving workloads between cluster nodes for maintenance or for smoothing out performance bottlenecks.

Imagine if you had 5 VMs running on one LUN in a 5 node cluster.  One of your cluster nodes is over-utilized and one is under-utilized.  If you were to move the 5-VM group to the under-utilized node then you might end up moving the bottleneck.  If the 5 VMs were split you could fail them over individually.  This would allow you to smooth out the utilizations more evenly.

Best Practice 2 – Fixed VHD files

VHD files can be Dynamic (i.e. the VHD is the size of the data in the VHD) or Fixed (i.e. the VHD is the size of the data and free space).  Having Fixed VHD files confers a performance benefit since there is no requirement to continually allocate new space to the VHD file.  Fixed VHD files also prevent performance issues caused by file fragmentation (especially when combined with one VM per LUN).

With these two best practices in mind I will now explain how they may affect your planning decisions around LUN sizing for a HA Hyper-V cluster.  My first attempt at planning my LUN sizes consisted of monitoring the physical servers I was going to virtualize for a period (in my case, three weeks) and extrapolating their observed data growth out to 3 years’ worth and then adding a 15% premium.  After that I rounded up to the nearest 5 GB and then ordered my LUNs from the SAN team.

My first mistake was that I forgot to factor in the amount of memory I planned to allocate to each VM in the calculations (a real beginner's mistake).  The next thing I didn’t think about until it came time to implement was that even though you might have a Fixed VHD file with 5 GB of free space inside that file, as soon as you take a snapshot, that 5 GB of free space becomes immediately inaccessible since now all changes are written to a differencing VHD file until the snapshot is deleted. 

So if you decide to go for both of the above best practices you really need to think hard about, not only  your LUN sizes, but also your management practices regarding snapshots.  In my environment I have decided that no Production VM will be allowed to run on a snapshot beyond a certain period.  So if you decide to make a snapshot of a VM prior to making a change, once the change is accepted and you have decided not to revert, then the snapshot should be deleted.  This will cause the changes to be committed to the original VHD on the next reboot.

If you decide to ignore best practice number 1 make sure you do it with your eyes open.  Know what you are getting yourself in for and have a bailout plan ready.  Oh and if you do ignore BP #1 I wouldn’t recommend ignoring BP #2.  The benefits of pooling VMs on a LUN are significant.  It simplifies your SAN configuration, reduces the chances that you will run out of drive letters on your parent partition and best of all you don’t have to make as many hard decisions about locking away disk space.  You can just go ahead and create a 1 TB LUN and start putting VMs on it, run with as many snapshots as you like and not worry.  Until you start to reach a performance bottleneck that is.

In summary, think hard about sizing your LUNs.  Consequences of under-sizing are significant, no room for snapshots, no room for boosting the amount of memory allocated to a VM.  If you have the luxury of copious amounts of SAN space (hey storage is cheap, right?) then overspec.

Notes:

• If you want to put more than 1 VM on a LUN and don’t want to have to write a script to do it, then you will want this hotfix (actually you will want it anyway, since the other changes in functionality it enables are invaluable for long term operations).
• If you group clustered VMs on a single LUN, don’t shut down the OS from within the OS or from Hyper-V Manager, this is not a cluster-aware shutdown and counts as a failure.  The OS will be restarted by the cluster and then if you go “what the ?!?!” and shut it down again, depending on how the cluster resource is configured this will induce a failover to another node, taking the rest of your VMs with it.  Try explaining that outage to your boss when a business critical server goes out of action for a couple of minutes at a crucial period because you shut down a scratch VM you had been using to test some software.  I for one do not feel like having to get a change request authorized just to shut down a machine.  Once you have made a VM a clustered VM, ALWAYS use Failover Cluster Management or the SCVMM Console to shut it down.

Have a listen to this podcast on SEO with Rob Veliz, then check out these tools:

Keyword Research: https://adwords.google.com/select/KeywordToolExternal

Keyword Research: tools.seobook.com/keyword-list/generator.php

Link Research: http://siteexplorer.search.yahoo.com/

Analytics: adCenter Add-inBeta for Excel 2007

Webmaster tools: http://webmaster.live.com/

Our first guest post (http://blogs.technet.com/tonyso/archive/2008/10/07/your-hyper-v-blog-post-here.aspx) comes from Jeremy Hagan. Thanks Jeremy!

Background:

One problem I have had when trying to do my first round of P2Vs for my Hyper-V implementation that I didn’t notice in testing is that you can’t size the VHD of the VM smaller than the corresponding physical disk of the original machine.  Since it is best practice to have one LUN per VM and it is also best practice to have fixed VHDs, this can cause a lot of wasted SAN space.  In my planning for the P2V process I monitored the target servers for 1 month so that I could get an idea of the CPU and memory use, but also the data growth.  I decided to plot the percentage of data growth, extrapolate this for 3 years and then add a 15% premium on top of this then rounded up to the nearest 5 GB.  This ended up being the SAN LUN size for each VM.  The problem I then had was that I didn’t have enough SAN space available to P2V my machines.

What I decided I needed to do was to P2V each machine to a sufficiently large scratch LUN, then shrink down the VHDs to be the size I wanted then migrate the VM off the scratch LUN to the desired LUN.  Easy right?  Well maybe not.  After much searching I have managed to come up with a recipe for doing this.  See the example below.  In this case it was a Windows XP machine with a 40 GB hard disk, but only 9.5 GB of data.  If you want to play with this I recommend making a copy of the VHD file as a backup rather than taking a snapshot.  Snapshots will interfere with final step using VHDResizer to create the final fixed VHD file.

Steps (assumes a single disk with a single partition):

1. Do your P2V as normal to a scratch disk that is big enough to hold all of the data from your physical machine and choose Dynamic for your disk types.
2. Bring up your physical machine, allowing any chkdsk that wants to run to complete successfully.  Boot into the operating system and defrag your C: drive:
   • Defrag C: -f –v
3. When the defrag has finished, use the precompact.exe tool (which was part of a Virtual Server R2 Service Pack 2) to write out all of the free space to zeros.  Failure to complete these last two steps has resulted in the following steps from failing.  I downloaded precompact.exe from here.
4. Now use Hyper-V manager to Compact the disk.
5. Connect the machine to bootable ISO Linux distro that includes NTFSRESIZE and FDISK.  I was playing around with free GHOST alternatives at the time and just happen to be using this one.
6. Boot to linux and login as root, then run:
   • Ntfsresize /dev/had1 –i
     This will report to you the smallest size to which you can shrink your NTFS MFT, like this  
7. Decide how small to resize your NTFS MFT to.  In this example the minimum is 9504 Mb.  I chose 9700 Mb so that the OS would have enough free space to boot cleanly.
   • Ntfsresize /dev/hda1 –s 9700M
     This will relocate any data needed then shrink the MFT. 
8. After this we need to shrink the partition, but the linux FDISK complains about the NTFS dirty bit, so we will allow our machine to boot to the OS and complete its chkdsk.  Detach the ISO and boot the OS allowing it to come all the way to the login prompt, do not skip the chkdsk.  For the sake of illustration I have logged in and taken a screenshot of Disk Manager showing the 9.6 GB NTFS, but a 37 GB Primary Partition,. 
9. Now boot back into the Linux distro and login as root.  Now we will delete the current partition and create a new one around the data we have there:
   • Run fdisk /dev/had
   • Press p to print the current partition info
   • Press d to delete the current partition
   • Press n to create a new partition:
     • Press p to select primary
     • Press 1 to create the first primary partition
     • Set the starting cylinder to be the same starting cylinder as the old partition (important!).  This is usually 1
     • Select the amount of space to use for the partition.  I chose only a little bigger than my NTFS size due to the vagaries of developers saying that 1 MB is 1000 KB or 1024 KB.  I put +10G
     • Press t to change the partition type and then select 7 for NTFS
     • Press a to make the partition bootable
     • Press p and review that the partition is correct
     • Press w to write the changes
        
   • Boot to the OS again to check that everything is working.  For the purposes of illustration I logged in and took a screenshot showing a 10GB partition and 27 GB of unallocated space. Shut down the VM.
10. Now we are ready to use a nifty little utility called VHDResizer to make a new, fixed-size VHD file, preferably in the same folder as the original dynamic one, which you will delete when you are done.  VHDResizer is available here.
    • Run VHDResizer
    • Open the Dynamic VHD that was created by the P2V process
    • Enter a path and filename of your new VHD file
    • Choose Fixed
    • Enter the size in GB
    • Click Resize
      
11. Now all we need to do is extend the partition and file system to take up the full disk.  I won’t spell out how to do it, but you can either boot to WinPE and use:
    • DISKPART:
      • SELECT VOLUME 0 or 1
      • DISKPART EXTEND
      • DISKPART EXTEND FILESYSTEM
    • Linux:
      • Use FDISK to delete the current partition and create a new one as above, but select the default for the end cylinder.
      • Run ntfsresize /dev/hda with no other arguments and it will extend to the maximum
12. Finished

Now if you think that is laborious and annoying, you’d be right.  Hopefully Microsoft will come up with a better way to do this in the future.  Now before I get a million comments about this, I did try to just use WinPE and DISKPART SHRINK, but no matter how many times I defragmented, precompacted and compacted I couldn’t get the partition to shrink down to less than about 24 GB.

Did you notice that the URL for search on TechNet changed recently?

It is now social.technet.microsoft.com/search.

Check out the new "refinements" (that work like "filters", only, I guess "filters" sounds too prole...) and the "Related To:" listings that bring you "pre-refined" searches, nifty.

Bothered by English-language results being categorized higher on the search results page than non-English results? Check out the new ability to exclude English results. 

Follow the Rob Veliz blog for more info.

When you migrate your Virtual Server or Virtual PC virtual machine to Hyper-V, you:

• remove the VM Additions
• move the VHD
• create a new VM
• install the Integration Services in the new VM

If you have trouble in this process, and it looks like the integration services did non install correctly (mouse doesn't work correctly, for example), you may have a HAL mismatch.

By default, Hyper-V will install an APIC MP HAL when the Integration Services are installed in the virtual machine. If the VM had a different HAL, try changing it.

To change the HAL

1. Open MSConfig

2. Click the Boot tab, and then click Advanced options…

3. Check Detect HAL, click OK twice, and then restart the virtual machine.