Zeros & Ones

When installed in a supported Linux virtual machine running on Hyper-V, the Linux Integration Components provide.

Driver support for synthetic devices: The Linux integration components include support for both the synthetic network controller and synthetic storage controller that have been developed specifically for Hyper-V. These components take advantage of the new high-speed bus, VMBus, which was developed for Hyper-V.

Fastpath Boot Support: Boot devices now take advantage of the storage VSC to provide enhanced performance.

Supported Host Operating Systems
This version of the Linux Integration Components supports the following versions of Hyper-V:
- Windows Server® 2008 Standard, Windows Server® 2008 Enterprise, and Windows Server® 2008 Datacenter (64-bit versions only)
- Microsoft® Hyper-V Server 2008
- Windows Server 2008 R2 Hyper-V RTM (Build 7600) Standard, Enterprise, and Datacenter
-Microsoft Hyper-V Server 2008 R2 RTM (Build 7600)

Supported Guest Operating Systems
This version of the Linux Integration Components supports the following guest operating systems and virtual CPU (vCPU) configurations:
-SUSE Linux Enterprise Server 10 SP2 x86 and x64 (1 vCPU)
-SUSE Linux Enterprise Server 11 x86 and x64 (1 vCPU)
-Red Hat Enterprise Linux 5.2, 5.3, and 5.4 x86 and x64 (1 vCPU)

To download Linux Integration component version 2, please click this link:-
http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=c299d675-bb9f-41cf-b5eb-74d0595ccc5c#filelist

Source

Hello, my name is Vipul Shah and I’m a Senior Product Manager with the Virtualization Team.

Due to its ability to drive down costs and drive up resource usage, Microsoft SQL Server consolidation is top of mind for our customers these days. Microsoft virtualization, which includes Windows Server 2008 R2 Hyper-V and System Center, is one of the well known mechanisms to enable this. Today, Ted Kummert, Senior Vice President, Microsoft Business Platform Division, released a video (click here) that outlines how virtualization enables consolidation.

So the natural question is – can we achieve higher amounts of throughput as we consolidate? Can we improve the throughput with recent advances in hardware and the recent release of Windows Server 2008 R2 Hyper-V?

To address this, we recently performed tests that are discussed in the Best Practices for SQL Server Virtualization webcast (click here) and in the SQL Server Consolidation Guidance (click here).

In our tests, we ran a complex stock trading application workload on servers with Second Level Address Translation (SLAT). In physical environments, the operating system translates virtual memory addresses to physical addresses. However with virtualization, we have an additional translation (the second level address translation) because you are running operating systems within virtual machines. This means additional CPU cycles are spent doing this translation. The SLAT enabled processors complete this translation within the silicon, leading to performance advantage compared with non-SLAT enabled CPUs. You get these processors from both Intel and AMD.

We chose a 16-core HP DL585 server with SLAT-enabled AMD processors with HP EVA 8000 storage running Windows Server 2008 R2 Hyper-V. We created virtual machines (VM) each with 4 virtual processors and 7 GB RAM using a fixed-sized VHD format. We started to run our workload with one VM and gradually increased the load, adding more VMs as we went along. We found that we were able to increase the throughput with consolidation. The workload scaled near-linearly up to 4 VMs consuming all of the physical cores on the server (16 cores total). Then we added even more VMs, consolidating up to 8 VMs. We over-committed virtual-processors to physical-cores ratio by 2:1. We were able to run heavy load (3000 batch requests per second), consuming about 70% CPU on the server. The tests also found that Windows Server 2008 R2 offered improved performance than the prior release as shown by the dotted red-line in the graph.

Microsoft virtualization (Hyper-V and System Center) combined with advances in hardware technology (such as SLAT-enabled technology) can provide a solid consolidation platform for production workloads using SQL Server.

Microsoft continues to work with partners to offer solutions that help our customers realize the benefits of virtualization (click here). Further guidance from our partners will be forthcoming. For more resources on virtualizing Microsoft server applications, click here.

Vipul Shah

Microsoft Virtualization Team, Senior Product Manager

Most of the times you may need to host some VMs on the Perimeter host, After adding this host to VMM console you still can't connect to the VMs on that host.

Your remote desktop connection failed because the remote computer cannot be authenticated..Certificate Errors.

Here you are the steps:

1. Open SCVMM console
2. Connect to  virtual host
3. you must be get attention and opportunity to save certificate from host
4. open mmc - certification - machine - <windows2008 R2 hyper-v host>
5. Add certificate to Personal folder
6. open mmc - certification - machine - <client>
7. Add certificate to Personal folder
8. Add central-CA  certificate from domain to Root Trust folder

Check it there

Gabe Knuth has wrote a very good article about Microsoft's Desktop Virtualization product line as of 2009

Last up in our rundown of the Big 5's desktop virtualization product lines is Microsoft.  This is probably the most ambiguous vendor, because so many of their products intertwine to make up their solution.  Many of those products have been around for a very long time, and in other capacities, so it's not easy to pick which products to focus on.  To make it easier, this article will only cover the products listed on Microsoft's Virtualization Products and Technologies website. (http://www.microsoft.com/virtualization/en/us/products-server.aspx)

Check it out there

This whitepaper defines the supported topologies and provides best practice recommendations for running Office Communications Server 2007 R2 and SQL Server™ 2008 in a Windows Hyper-V environment or other hypervisor technologies.

Overview

“If you think technology can solve your security problems, then you don’t understand the problems and you don’t understand the technology.”
– Bruce Schneier

A great post about adding new VMs automatically in the DPM 2010 protection.

DPM team had a great question come into the DPM Newsgroup recently. How do I automatically protect new VMs added to a Hyper-V host using DPM?

In any virtualized environment, adding new VMs is a frequent operation. While backup administrators can protect an entire Hyper-V host using the DPM Management Console, the protection group had to be modified manually to include the new virtual machines that have come up on the Hyper-V host.

Angad, who closely follows the DPM community immediately got going and came up with scripts to support the requested functionality. These scripts have been validated in our in-house Hyper-V protection scale runs.

You can find the scripts here.

I was facing this problem during the last month till I found this update, My testing server was holding around 12 VMs ( AD, Exchange 2010, SCOM, SCCM, TMG, etc... ) and we were facing a network problem, In heavy network loads some of the VMs got a disconnected NIC.

I found that TMG's team is facing the same problem...

If you've deployed your ISA Server, Microsoft IAG, Forefront TMG or Forefront UAG on Hyper-V R2 and noticed that a connection between the guest and the virtual switch starts "acting odd", performs poorly or becomes disconnected entirely, you  may want to apply this update:

http://support.microsoft.com/kb/974909

Consider the following scenario:

• You install the Hyper-V role on a computer that is running Windows Server 2008 R2.
• You run a virtual machine on the computer.
• You use a network adapter on the virtual machine to access a network.
• You establish many concurrent network connections, or there is heavy outgoing network traffic.

In this scenario, the network connection on the virtual machine may be lost. Additionally, the network adapter is disabled.

Note You have to restart the virtual machine to recover from this issue.

You have to install this hotfix for this problem, Now everything is fine

Source

It’s all available at : http://technet.microsoft.com/en-us/dd565807.aspx

Source: Ask the Core Team

Windows Server 2008 R2 has been publicly available now for only a short period of time, but we are already seeing a good adoption rate for the new Live Migration functionality as well as the new Cluster Shared Volumes (CSV) feature. I personally have worked enough issues now where Live Migration is failing that I felt a short blog on what process I have followed to work through these may have some value.

It is important to mention right up front that there is information publicly available on the Microsoft TechNet site that discusses Live Migration and Cluster Shared Volumes. This content also includes some troubleshooting information. I acknowledge that a lot of people do not like to sit in front of a computer monitor and read a lot of text to try and figure out how to resolve an issue. I am one of those people. Having said that, let’s dive in.

It has been my experience thus far that issues that prevent Live Migration from succeeding have to do with proper network configuration. In this blog, I will address the main network related configuration items that need to be reviewed in order to be sure Live Migration has the best chance of succeeding. I begin with an initial set of assumptions which include the R2 Hyper-V Failover Cluster has been properly configured and all validation tests have passed without failure, the highly available VM(s) have been created using cluster shared storage, and the virtual machine(s) are able to start on at least one node in the cluster.

I start off by identifying the virtual machines that will not Live Migrate between nodes in the cluster. While it should not be necessary in Windows Server 2008 R2, I recommend first running a ‘refresh’ process on each virtual machine experiencing an issue with Live Migration. I say it should not be necessary because a lot of work was done by the Product Group to more tightly integrate the Failover Cluster Management interface with Hyper-V. Beginning with R2, virtual machine configuration and management can be done using the Failover Cluster Management interface. Here is a sample of some of the actions that can be executed using the Actions Pane in Failover Cluster Manager.

If virtual machine configuration and management is accomplished using the Failover Cluster Management interface, any configuration changes made to a virtual machine should be automatically synchronized across all nodes in the cluster. To ensure this has happened, I begin by selecting each virtual machine resource individually and executing a Refresh virtual machine configuration process as shown here –

The process generates a report when it completes. The desired result is shown here –

If the process completes with a Warning or Failure, examine the contents of the report and fix the issue(s) that was reported and run the process again until it successfully completes.

If the refresh process completes without Failure, try to Quick Migrate the virtual machine to each node in the cluster to see if it succeeds.

If a Quick Migration completes successfully, that confirms the Hyper-V Virtual Networks are configured correctly on each node and the processors in the Hyper-V servers themselves are compatible. The most common problem with the Hyper-V Virtual Network configuration is that the naming convention used is not the same on every node in the cluster. To determine this, open the Hyper-V Management snap-in, select the Virtual Network Manager in the Actions pane and examine the settings.

The information shown below (as seen in my cluster) must be the same across all the nodes in the cluster (which means each node must be checked). This includes not only spelling but ‘case’ as well (i.e. PUBLIC is not the same as Public) –

It is important to be able to successfully Quick Migrate all virtual machines that cannot be Live Migrated before moving forward in this process. If the virtual machine can Quick Migrate between all nodes in the cluster, we can begin taking a closer look at the networking piece.

Start verifying the network configuration on each node in the cluster by first making sure the network card binding order is correct. In each cluster node, the Network Interface Card (NIC) supporting access to the largest routable network should be listed first. The binding order can be accessed using the Network and Sharing Center, Change adapter settings. In the Menu bar, select Advanced and from the drop down list choose Advanced Settings. An example from one of my cluster nodes is shown here where the NIC (PUBLIC-HYPERV) that has access to the largest routable network is listed first.

Note: You may also want to review all the network connections that are listed and Disable those that are not being used by either the Hyper-V server itself or the virtual machines.

On each NIC in the cluster, ensure Client for Microsoft Networks and File and Printer Sharing for Microsoft Networks is enabled (i.e. checked). This is a requirement for CSV which requires SMB (Server Message Block).

Note: Here is where people get into trouble usually because they are familiar with clusters and have been working with them for a very long time, maybe even as far back at NT 4.0 days. Because of that, they have developed a habit for configuring cluster networking which basically is outlined in KB 258750. This article does not apply to Windows Server 2008.

Note: If CSV is configured, all cluster nodes must reside on the same non-routable network. CSV (specifically for re-directed I/O) is not supported if cluster nodes reside on separate, routed networks.

Next, verify the local security policy and ensure NTLM security is not being restricted by a local or domain level policy. This can be determined by Start > Run > gpedit.msc > Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options. The default settings are shown here –

In the virtual machine resource properties in the Failover Cluster Management snap-in, set the Network for Live Migration ordering such that the highest speed network that is enabled for cluster communications and is not a Public network is listed first. Here is an example from my cluster. I have three networks defined in my cluster –

The Public network is used for client access, management for the cluster, and for cluster communications. It is configure with a Default Gateway and has the highest metric defined in the cluster for a network the cluster is allowed to use for its own internal communications. In this example, since I am also using ISCSI, the ISCSI network has been excluded from cluster use. The corresponding listing on the virtual machine resource in the Network for live migration tab looks like this –

Here, I have unchecked the iSCSI network as I do not want Live Migration traffic being sent over the same network that is supporting the storage connection. The Cluster network is totally dedicated to cluster communications only so I have moved that to the top as I want that to be my primary Live Migration network.

Note: Once the live migration network priorities have been set on one virtual machine, they will apply to all virtual machines in the cluster (i.e. it is a Global setting).

Once all the configuration checks have been verified and changes made on all nodes in the cluster, execute a Live Migration and see if it completes successfully.

Bonus material:

There are configurations that can be put in place that can help live migrations run faster and CSV to perform better. One thing that can be done, is to Disable NetBIOS on the NIC that will be supporting the primary network used by CSV for re-directed I/O. This should be a dedicated network and should not be supporting any other traffic other than internal cluster communications, redirected I/O for CSV and\or live migration traffic.

Additionally, on the same network interface supporting live migration, you can enable larger packet sizes to be transmitted between all the connected nodes in the cluster.

If, after making all the changes discussed here, live migration is still not succeeding, then perhaps it is time to open a case with one of our support engineers.

Thanks again fro you time, and I hope you have found this information useful. Come back again.

Additional resources:

Using Live Migration with Cluster Shared Volumes in Windows Server 2008 R2

High Availability Product Team Blog

Hyper-V and Virtualization on Microsoft TechNet

Windows Server 2008 R2 Hyper-V Forum

Windows Server 2008 R2 High Availability Forum

Chuck Timon
Senior Support Escalation Engineer
Microsoft Enterprise Platforms Support

Source

If so the Technet Script Center has plenty of resources, view them here

Some scripts I’d like to highlight:

Virtual Machine Management

Configure Guest OS for VDI (PowerShell)

Configure Guest OS for VDI (VB Script)

Virtual machine assignment management

Bulk assign virtual machines to users or pools

List VM assignment information

Infrastructure setup: RD Connection Broker cluster creation and management

Manage RD Connection Broker cluster (create, add nodes)

Update RD Connection Broker configuration across nodes in a cluster

Troubleshooting

Configuration verification

Monitoring and Reporting:

Monitor sessions

Generate usage report