It is important to get the network card configuration right in the parent partition for Hyper-V in Windows Server 2008/R2. 

Common problems include:

• A-Records and PTR’s registered for the Parent Partition under multiple IP addresses
• NetBIOS conflicts
• Unwanted traffic going through network cards that you want to dedicate to, for example, VM’s or iSCSI.

These problems have nothing to do with Hyper-V actually.  They’re just issues you can face with any server containing more than one network card.

Step #1: Ensure that you have a good naming convention for you network cards

As you can see I have explicitly named by network cards.  One for the parent partition, one for the VM’s.  If you have one or more network cards for VM’s or iSSCI, name them accordingly.

Step #2 : Ensure that the parent partition uses the right network card

In the image below you can see that the Parent Partition network card is first in the order.  This means that network services will attempt to use this interface before the VM NIC #1.

Step #3 : Ensure that the VM or iSCSI NIC does not register itself in DNS

Make sure that the network cards you dedicate for VM external networks do not register themselves in DNS.  Just configure the basic IP address and mask.  You do not need to include DNS servers etc.  Remember, you are more or less turning this network card into a virtual switch.

Note that the “Register this connections addresses in DNS” is left un-ticked.  If you built you base OS for the parent partition with all the network cards patched, chances are that you will find more than one address registered for the server in DNS.  Ensure that you remove unwanted A-records and PTRs.

Step #4: Ensure that you disable NetBIOS over TCP/IP on the VM network cards

I was recently asked a question about PowerShell's ability to read in an XML configuration file at a Virtual Academy I ran last week.  One of the strengths of PowerShell is its ability to perform lots of time saving tasks … one of which is reading in an XML file.  The Get-Content command can read in an XML file and you can easily loop through the contents.

Example:

[xml]$computerlist = Get-Content computers.xml
foreach( $computer in $computerlist.computers.target) 
{ 
    Write-Host $computer.name
} 

What would the XML file look like?

<computers> 
  <target> 
    <Name>server1</Name> 
  </target> 
  <target> 
    <Name>server2</Name> 
  </target> 
</computers>

Nice and simple really.

“Although bulk deletions are rare, they are disruptive events that you can guard against by removing the Delete and the Delete Subtree permissions in Active Directory. To guard against accidental deletions, you should remove the Delete and Delete Subtree permissions on organizational units (OUs) that contain user accounts, computer accounts, and security groups in Active Directory. You should also remove the Delete All Child Objects permission on the parent container of an OU that you want to protect.”

This above is taken from http://technet.microsoft.com/en-us/library/cc773347(WS.10).aspx 

The TechNet article then shows you how to manually, through the GUI, modify the access control entries (ACE’s).  You can find details here.  

So, how do you go about this task if you have quite a few OU’s?  You need the following from the Windows Server 2003 Support tools:

• dsquery
• dsacls

dsquery will, by default, only return the first 100 results.  You’ll need the ‘–limit 0’ to process more than 100 objects, in this case OUs.

To protect all OU’s in a domain run the following:

for /F "tokens=*" %%i in ('dsquery OU -limit 0') do dsacls %%i /D "EVERYONE:SDDCDT"

To protect a specific OU and all leaf OU’s:

for /F "tokens=*" %%i in ('dsquery OU “ou=target,dc=domain,dc=net” -limit 0') do dsacls %%i /D "EVERYONE:SDDCDT"

For /F “tokens=*" %%i in ('dsquery OU –limit 0') do dsacls %%i /S

With the economic down turn and the green agenda Virtualisation has become a hot topic with my customer. These days its all about getting the best value for money as possible with your IT budget, so when my customer had a number of servers out of warranty and due for replacement the Hyper-V platform was the first port of call.

The first thing we did was run the Microsoft MAP tool against these servers to ensure that they were real candidates for Virtualisation. This tool can be found at

http://www.microsoft.com/downloads/details.aspx?familyid=67240B76-3148-4E49-943D-4D9EA7F77730&displaylang=en

Information on using the tool can be found at

http://technet.microsoft.com/en-us/library/bb977556.aspx

Currently my customer has a number of Hyper-V GEO Cluster's based on HP boot from SAN Blades. All  of the Virtual Hosts are managed centrally by Microsoft System Centre Virtual Machine Manager (SCVMM). Using the map tool we were able to determine that based on the existing hardware we could achieve an 8 - 1 virtual machine ratio. Considering that the new hardware runs cooler / cheaper and is only a couple of U per blade compared to the 6 - 8 U servers they were replacing everyone was happy.

All of the machines to be Virtualised were Windows 2000 & ran bespoke applications. If we were to rebuild these servers on new kit it would have taken a lot of time and effort to ensure that the applications were tested etc.. not to mention the downtime involved.

Pre-Requisites

You will need the following patches on the Hyper-V target systems.

KB950050, KB951308, KB956589, KB956697, KB956710, KB956774

You will need the following patch on the SCVMM Server

KB959596

You will also need the following version of WAIK for all offline conversions. The version included with the OS will not do the job. Install this on the SCVMM Server.

http://www.microsoft.com/downloads/details.aspx?familyid=C7D4BC6D-15F3-4284-9123-679830D629F2&displaylang=en

Using the P2V Wizard

In this example I am performing a physical to virtual conversion on a Windows 2000 server.

A Windows 2000 server P2V has the following pre-requsites.

• Service Pack 4
• 512MB RAM minimum

As the source service is Windows 2000 the only option is an offline conversion. As part of the process an agent will be installed on the source server and the server will be re-booted into WinPE so that the contents of the source servers hard drive can be copied via BITS.

1. With the Virtual machines menu option high lighted click on Convert Physical Server.

2. Enter the Computer name or IP address of the Physical Server and account details of a user that has local administrator rights on the source Physical Server.

3. Enter a Name for the New Virtual Server. Set the owner of the Virtual Machine (defaults to the logged in user) and add a description for the Virtual Server.

4. Click Scan System to install the SCVMM agent & gather information on the Physical Server.

5. After the scan the System Information panel will be populated. Click Next to continue.

6.  Here we select the volumes to be copied to the new VM as part of the P2V process. You can also change the VHD type from Dynamic to Fixed.

7. Typically on this screen I choose to obtain an IP address automatically from DHCP. You can specify an IP address & Network card (using MAC address) if required.

8.  On this screen you can specify the number of process and amount of RAM the VM will use. I usually set the VM to use 2 processors during the P2V process. This helps with the integration components setup, it can be changed back to a single processor later. Please note that these settings will be used to determine the placing of the VM on a host server as we will see later.

 

9. Here you choose the server that will host the VM. You can see the suitability of each host based on the Star Rating. This is much improved when SCOM is used in conjunction with SCVMM. In the screen shot below SCOM was not configured.

10. As the host I selected was a Windows 2008 Hyper-V cluster I got this message box popping up. Click Yes to continue. SCVMM will set up the new virtual server as a clustered VM.

11. Select the volume that the VM will reside on. If your target volume does not appear on this list refresh the cluster information within SCVMM.

12. Select the Virtual Network that the Virtual Machine will use.

13. As this VM will reside on a cluster do not change these settings. This allows the cluster service to manage the Virtual Machine.

14. If all is ok you should see this screen. You can run into an issue that can occur  with legacy hardware (i.e. RAID controllers) not included with the WINPE Image, which is used to boot into the P2V environment . If you can obtain the Vista driver for the problem hardware copy it to SCVMM\Drivers\Import folder to solve the issue.

 

 

15. This last screen gives us a summery of the P2V job & the option to View and copy the PowerShell script generated by the wizard. You can copy out this script and modify it for automating this process if required.

 

16. After clicking Create the jobs screen will pop up. This screen provides real time information regarding the P2V process including the time required to copy the contents of the targets volumes to the new virtual machine.

 

17. Here we can see the BITS copy in progress and the amount of time remaining to copy the volumes.

18. The script we created with the Wizard also installs the required virtual machine components. In some cases this process will seem to hang. This can be resolved by using the Hyper-V console on the target machine to re-start the VM.

 

20. Once the jobs screen completes we will have a running Windows 2000 VM. Check that the VM is running on the External Virtual Network and that the source machine is turned off and removed from the Network.

The process was quick with minimal downtime for the users. We did run into some issues with legacy RAID controllers but got around them using the fix mentioned in step 14. The new VM’s are a lot more stable than the previous hardware and are now on a high availability platform giving my customer more peace of mind.

One of the most common conversations I have about virtualisation is the "how do I make my virtual machines highly available?" one.  Topics like Hyper-V Quick Migration are then discussed and off the techie goes to start testing.  When I revisit the discussion I have noticed the false sense of security people get just because their virtual machines are highly available.  HA options for VM's do not mean stop worrying about host clustering, network load balancing or traditional backups  ...  no matter how clever the technology.  Highly available virtual machines no longer have the single point of failure at the (host) hardware level .. and that's about as far as it goes.  You still have to mitigate against the same risks at the OS level (and above) regardless of whether or not its physical or virtual.  Okay, some of you are saying duh!  Bear with me though.  It's not uncommon for people to think just because they have a Hyper-V cluster or VMWare HA that the majority of potential outages are accounted for.

Consider the following:

1. Most HA options will require that the host(s) is/are functioning correctly.  If you have problems with the host, expect problems with your HA solution.
2. Replication of virtual hard disks will not protect you from data loss or corruption inside VM.  The loss will be replicated.
3. Replication of virtual hard disks will not protect against corruption of virtual hard disks or settings.  The corruption will be replicated.
4. Live migration options really only work for planned downtime.  Unplanned downtime will result in your VM's being restarted with a (varying) loss of service.

With the above in mind, have  a read of the following:

• Hyper-V Hardware considerations
• Backing Up Hyper-V Virtual Machines
• Hyper-V Clustering Options
• Design for a Failover Cluster in Which All Nodes Run Hyper-V 
• Requirements and Recommendations for Failover Clusters in Which All Nodes Run Hyper-V   
• Checklist: Failover Cluster in Which the Servers Run Hyper-V   

Long story short, virtualisation has not changed anything when it comes to mitigation against system failure/outage.  The same rules still apply.  Virtualisation high availability solutions represent only the first layer of protection .. just don't forget the other options like:

• Traditional Backup and Recovery
• Host Clustering
• Network Load Balancing