System Center: Virtual Machine Manager Engineering Team Blog

KB: A live migration of a non-clustered virtual machine in Virtual Machine Manager fails with error 0x8007274D

J.C. Hornbeck — Wed, 19 Jun 2013 16:15:42 GMT

Just a quick FYI on a new Knowledge Base article we published today. This one talks about an issue where an attempt to perform a live migration on non-clustered virtual machines (shared nothing live migration) from one host to another will show a zero rating for the desired host and display the following text in the Rating Explanation field:

Migration check for virtual machine <serverName> failed to create a planned virtual machine in the target host. Detailed error message: The Virtual Machine Management Service failed to establish a connection for a Virtual Machine migration with host serverName.contoso.com: No connection could be made because the target machine actively refused it. (Ox8007274D).

You can get all of the details in the article below:

KB2853203 - A live migration of a non-clustered virtual machine in Virtual Machine Manager fails with error 0x8007274D (http://support.microsoft.com/kb/2853203)

J.C. Hornbeck | Knowledge Engineer | Microsoft GBS Management and Security Division

Get the latest System Center news on Facebook and Twitter:

System Center All Up: http://blogs.technet.com/b/systemcenter/
System Center – Configuration Manager Support Team blog: http://blogs.technet.com/configurationmgr/
System Center – Data Protection Manager Team blog: http://blogs.technet.com/dpm/
System Center – Orchestrator Support Team blog: http://blogs.technet.com/b/orchestrator/
System Center – Operations Manager Team blog: http://blogs.technet.com/momteam/
System Center – Service Manager Team blog: http://blogs.technet.com/b/servicemanager
System Center – Virtual Machine Manager Team blog: http://blogs.technet.com/scvmm

Windows Intune: http://blogs.technet.com/b/windowsintune/
WSUS Support Team blog: http://blogs.technet.com/sus/
The AD RMS blog: http://blogs.technet.com/b/rmssupp/

App-V Team blog: http://blogs.technet.com/appv/
MED-V Team blog: http://blogs.technet.com/medv/
Server App-V Team blog: http://blogs.technet.com/b/serverappv

The Forefront Endpoint Protection blog : http://blogs.technet.com/b/clientsecurity/
The Forefront Identity Manager blog : http://blogs.msdn.com/b/ms-identity-support/
The Forefront TMG blog: http://blogs.technet.com/b/isablog/
The Forefront UAG blog: http://blogs.technet.com/b/edgeaccessblog/

Logical Networks (Part V) – Network Virtualization

Nigel Cain [MSFT] — Mon, 17 Jun 2013 17:11:57 GMT

In this post, we complete our review logical networks by looking at the implications of Network Virtualization and Externally Defined Networks on your logical network design. Note that in the latter case, the VMM administrator has no insight into how the network is constructed, nor do they have any visibility into the method of network isolation that has been applied.

This blog also marks the final posting dedicated to Logical Networks in SC VMM 2012 SP1. In the next and subsequent posts we change focus, moving on to discuss uplink and network adapter port profiles, port classifications and logical switches. Thanks for staying with us this far, hope you find the future posts just as useful.

Look forward to your feedback and comments.

Nigel Cain & Damian Flynn

Introduction

In VMM 2012 SP1 you can isolate VM Networks using either traditional VLAN/PVLANS or, if you are using Windows Server 2012 as your host operating system, you can choose to implement Network Virtualization. The latter option addressing the scale limitations associated with a traditional VLANs solution as well as allowing tenants to “bring their own network” or otherwise extend their network into your environment. The diagram at the link below shows each of these options and acts as a reference for the detailed discussion that follows.

http://www.microsoft.com/en-us/download/details.aspx?id=37137

In this post, we complete our coverage of logical networks with a discussion of how to isolate workloads with Network Virtualization and externally defined networks.

Network Virtualization

Network Virtualization introduced in Windows Server 2012 Hyper-V provides administrators with the ability to create multiple virtual networks on a shared physical network. In this approach to isolation, each tenant gets a complete virtual network, which includes support for virtual subnets and virtual routing. Tenants can even use their own IP addresses and subnets in these virtual networks, even if these conflict with or overlap with those used by other tenants. Further, since virtual networks are defined entirely in software, it is not necessary to reconfigure the physical network (unlike VLANs and PVLANS solutions) to onboard or remove tenant networks or to make changes to reflect new business requirements. You can find more details on this approach at the link below:

http://blogs.technet.com/b/windowsserver/archive/2012/08/22/software-defined-networking-enabled-in-windows-server-2012-and-system-center-2012-sp1-virtual-machine-manager.aspx

In the example below, tenant A has two virtual subnets. A virtual router automatically created by Windows Server 2012 Hyper-V connects the two subnets for this tenant and allows virtual machines on each subnet to communicate with each other. Tenant B has a single virtual subnet but still has its own virtual router. The virtual subnet ID and Routing Domain ID shown in the diagram are used by Hyper-V host computers to differentiate network traffic and routing for each of the tenants.

Note: The virtual router does not exist on any one host. It essentially spans all hosts that contain virtual machines that are part of a particular VM network

When using Network Virtualization, your logical network design is relatively simple – create a single Logical Network for all of your customers that will be isolated from each other using network virtualization and configure the properties of the network to “allow new VM Networks created on this network to use network virtualization”.

As with before, you need to create network sites to define the VLANs and IP subnets that are to be associated with the Logical Network in each physical location. Assuming you specify VLANS in your network sites, the physical network must be able to route network traffic between them – VLANS in this case are used by the network administrator for ease of management and control broadcast traffic, they are not used as an isolation mechanism.

Note that An IP Pool must be associated with every single Network Site lined to the logical Network. The IP addresses from these pools, also known as Provider Addresses (or PA) pools, must also be routable between all of the Hyper-V hosts associated with the Logical Network.

You will need to create VM Networks to allow customer virtual machines to connect to and use the Logical Network and you should define a separate VM Network for each tenant, with each one of these VM Networks configured to isolate using Hyper-V network virtualization as shown below. You can also select No Isolation if you want to have the VM network provide virtual machines with direct access to the logical network – a configuration which essentially replicates the behavior found in SC VMM 2012.

Note: The radio button to enable isolation is only available when Provider IP Addresses pools have been defined for the IP protocol (IPv4 or IPv6) supported by the Logical Network as we discussed above.

You also need to define the IP Subnets for each VM Network, setting out the IP addresses that will be used by Virtual Machines connected to that Network. These addresses otherwise known as Consumer Addresses (CA) are completely separate from any other tenant and from the Logical Network and tenants can therefore use their own IP addresses and subnets in their virtual networks, even if these appear to conflict with or otherwise overlap with those used by other tenants. As discussed earlier, each tenant may be allocated multiple subnets as shown in the example below and if this is the case, the Hyper-V host will automatically create a virtual router to ensure that virtual machines on each of these subnets are able to communicate with each other.

Note: VMM installs a DHCP Virtual Switch extension on each host which it manages. If a tenant’s Virtual Machine uses DHCP to request an IP address, the extension will respond by offering an IP address from the IP pool that has been defined for the VM Network.

The Virtual Machine Networks discussed above have no external connectivity by default, meaning that virtual machines connected to them will only be able to communicate with other virtual machines on the same VM Network . A VPN Gateway device can be used to provide a VPN tunnel to a nominated external network or a NVGRE Gateway device to allow virtual machines on the virtual network to communicate with other networks in the local datacenter.

The remote and local networks options (highlighted) are greyed out in the dialog below as no gateway “provider” has been defined in the current installation of SC VMM. The first “production capable” NVGRE gateways that can be registered and configured for use with VM Networks are starting to become available. Microsoft is continuing to work with vendors in this space and is working to provide an “inbox” gateway in the next release of SC VMM..

To briefly summarize, create a single Logical Network for tenants that are to be isolated using Network Virtualization, configured to “allow new VM Networks created on this network to use network virtualization”, defining Network Sites and IP Pools for each location in which the network will be supported. If Network Sites Create VM Networks for each tenant and specify the IP Subnets that they will use. The net result should be a 1 to many mapping between the Logical Network and VM Networks created to support each tenant as shown below:

Externally Defined Networks

Network administrators can optionally configure network settings or capabilities such as logical networks, network sites and IP pools in third party (vendor) network management console and, through a virtual switch extension manager, import these directly into VMM. This approach allows network specialists to focus on and define the logical network, leaving the VMM administrator free to concentrate on the VM Networks and the services that are to be offered to end customers. In this context, the logical network becomes a “black box” to the VMM administrator, in that they can use networks imported through the virtual switch extension manager but have no insight into how the network is constructed, nor do they have any visibility into the method of network isolation that has been applied to a given network as shown below.

We note externally defined networks here only in the sense that VMM administrators need to work closely with their counterparts in the network team to make sure that a consistent model and design structure is being followed. Ideally, network administrators should plan and work out the network configuration in partnership with VMM administrators to ensure that both parties agree on naming conventions and standards for how to define the fabric. You can find more information on virtual switch extension managers in VMM and how to make use of them at the following location:

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

Summary

There are a number of reasons why you might need to create a Logical Network; to facilitate the movement of virtual machines and services across different physical locations, apply settings and capabilities to hosts or virtual machines that have specific network requirements or which require guaranteed service levels, to isolate network traffic or to facilitate access to networks that are configured through / managed by third party network management tools.

In looking at the Logical Networks we created in our example organization, there appears to be little or no requirement to isolate any of the Logical Networks we defined on top of the Datacenter Physical Network. That being said, we could easily justify using some form of isolation for front end web servers (assuming they were accessible from the public Internet) or where we have specialised servers and workloads that need to be isolated from others. As we discussed, you need to assess each logical network and determine what, if any, isolation methodologies you should apply.

The case for isolation for Logical Networks on the provider network is very clear however in that there are multiple customers running workloads on the same physical infrastructure. Where a given physical network or VLAN(S) has been dedicated to a particular customer, clearly no isolation will be required on the Logical Network – only that tenant’s traffic will exist on the network. However, in the case of shared networks, we need to consider which isolation method is best suited both to the customers’ requirements and is supported by the physical network. Network Virtualization clearly offers the most comprehensive and scalable solution but requires NVGRE Gateway Devices to allow virtual machines to communicate with networks in the same Datacenter or VPN Gateway devices to facilitate communication with a defined external network. VLAN/PVLAN isolation can be readily used, is well understood and is supported by most existing network hardware but has management issues at scale. The decision, ultimately, will be based on your business strategy, current and forecast growth patterns and how quickly /easily you can acquire and deploy network gateways that support NVGRE and software defined networking.

There clearly is no clear and simple answer to the question “how many Logical Networks do I need”, since the number will depend on your business requirements, your physical network and any constraints that exist in your physical environment. These blog post should go some way to helping you to identify the set of logical networks you need and the design that is right for your business.

Logical Networks (Part IV) – PVLAN Isolation

Nigel Cain [MSFT] — Tue, 04 Jun 2013 16:30:15 GMT

In this blog, we continue our review of tenant isolation by looking at the implications of PVLANs on your logical network design – we will look at Network Virtualization and complete our review of Logical Networks in the next post. We Look forward to your feedback and comments.

Nigel Cain & Damian Flynn

Introduction

http://www.microsoft.com/en-us/download/details.aspx?id=37137

In Part III – Network Isolation, we covered how to configure your Logical Network for “No Isolation” in cases where you do not need to separate workloads and what you should do / how you should design your logical network solution when you want to use traditional VLANS. In this post, we focus our attention on isolation using PVLANs.

PVLAN Isolation

Private Virtual LANs (PVLANS) are often used by Service Providers (Hosters) to work around the scale limitations of VLANS that we discussed in Part III. They essentially allow network administrators to divide a VLAN into a number of separate and isolated sub-networks which can then be allocated to individual customers (tenants). PVLANs share the IP subnet that was allocated to the parent VLAN, as you might expect, but, from a security perspective, although hosts connected to different PVLANs still belong to the same IP subnet, they require a router to communicate with each other and with resources on any other network.

A PVLAN consists of a Primary and Secondary VLAN pair - each machine that is part of a PVLAN pair can be configured in one of three modes as shown below. In Promiscuous mode, hosts are on the primary VLAN and are able to communicate directly with resources on the primary VLAN and also the secondary VLAN. In a Community mode, the secondary VLAN represents a community. Direct communication is permitted only with hosts in the same community and those that are connected to the Primary PVLAN in promiscuous mode. Isolated PVLANs are pretty much as described, in that direct communication is permitted only with promiscuous resources that exist in the Primary PVLAN.

SC VMM 2012 SP1 only supports isolated mode (as described above) and has no concept of primary (promiscuous) or community modes. What this means in practice is that a Virtual Machine connected to a PVLAN in this release is completely isolated from any other resources on the network. The only device it can directly communicate with is the default IP gateway. While this may feel like a severe limitation, there are a number of scenarios which work quite well in this configuration - the most common example of which is Front End Web Servers. In this specific scenario, all of the web servers in a web farm are placed on a single network subnet but are otherwise completely isolated from each other, PVLANs in this context helping to simplify management and improve overall security.

Note: Similar functionality to community mode can be achieved by adding second network adapter to each isolated virtual machine and connecting this adapter to a VM Network on which network virtualization has been enabled and to which (all) of the other “community” resources are also connected.

Returning to Logical Network design, you should create a single Logical Network when using PVLANs, configuring the properties of the Logical network (as shown below) to specify that “sites within this logical network are not connected” and “Network sites within this logical network contain private VLANs”.

The Networks Sites page of the Create Logical Network wizard includes a subtle but important difference for PVLANs – in addition to the primary VLAN, the “Associated VLANs and IP Subnets” section now contains an additional column Secondary VLAN. You should associate each primary VLAN and secondary PVLAN with a Network site within the logical network (as shown below) – you can define multiple PVLANS in the same Network Site as needed.

Note: Only one PVLAN can be in isolated mode per primary VLAN and you should take care to ensure that a different primary VLAN ID is used in each Network Site you create. The ID you use for the PVLAN, however, may be the same in each site – in fact using the same ID for the isolated PVLAN is recommended since it ensures consistency and simplifies management.

As before, VM Networks need to be created to allow virtual machines to connect to and use the Logical Network. Each VM Network you create is directly mapped to exactly one of the PVLANS that have been defined for that Logical Network. As a result, you can only have as many VM Networks as you have defined PVLANS. The create VM Wizard (below) will display only those PVLANS that have not already been allocated to an existing VM Network. The wizard does not offer the option for automatic assignment - even though the text suggests that this is actually possible.

To briefly summarize, create a single Logical Network to support PVLAN isolation, configured such that “sites within the logical network are not connected” and “Network sites within the logical network contain Private VLANs”. You should create a Network Site, define primary and secondary VLAN pairs and create VM Networks for each one (as shown below). In our example, we have chosen to designate PVLAN 5 as the isolated PVLAN for consistency across all primary VLANs, your implementation may be different.

As we discussed earlier, although each virtual machine you connect to one of these VM Networks will be assigned an IP address from the same subnet, it will only be able to communicate only with the default IP gateway. You should also be aware that If all of the virtual machines are present on the same physical host, isolation will be enforced through the Hyper-V Extensible Switch, otherwise you will need to make sure that each of the PVLANS you define in VMM are also configured for isolation mode on the Physical Switch.

To avoid potential IP conflicts with resources that exist on the primary VLAN (and any community VLANS that were created outside of VMM), it is recommended that you reserve a set of IP addresses / create a separate IP Pool for each PVLAN. As discussed, the IP addresses you reserve must be part of the IP subnet that was allocated to the primary VLAN.

Summary

SC VMM 2012 SP1 only supports isolation mode and has no concept of primary (promiscuous) or community PVLANS and you need to be aware of this restriction when designing your solution. That being said, there are a number of scenarios which work quite well in this configuration - the most common example of which is Front End Web Servers. In this specific scenario, all of the web servers in a web farm are placed on a single network subnet but are otherwise completely isolated from each other, PVLANs in this context helping to simplify management and improve overall security.

Free Whitepaper and Webinars on Virtual Networking from MVP Damian Flynn

Travis Wright MSFT — Fri, 31 May 2013 17:32:20 GMT

One of our ISV partners, Savision, has been working with one of the System Center Cloud and Datacenter Management MVPs, Damian Flynn, to produce a whitepaper on virtual networking. Damian will also be hosting two free webinars on the topic. Details below.

Cloud & Datacenter MVP, Damian Flynn, who is the author of the whitepaper: 'The Next Episode; Unravelling the Network with SCVMM 2012' will be presenting a free webinar on the top[ic ‘Unraveling the network with SCVMM 2012’.

With the launch of Windows Server 2012 Hyper-V, Microsoft introduced to the world its solution for Software Defined Networks using System Center Virtual Machine Manager 2012 SP1. In this whitepaper, commissioned by Savision, Damian outlines the concepts, benefits and steps you need to take to embrace your own “Virtual Network”. In addition to the whitepaper, Damian will host two exclusive webinars on the same topic.

Click here to download this complimentary whitepaper.

We will also be hosting two webinars in which Damian will personally discuss the content of the whitepaper and will provide further information, don't miss them! The webinars will be hosted on the 11th of June at 10 AM EST and on the 13th of June at 11 AM CET.

Click here to register for the webinars.

Don't miss the opportunity to learn more from an acknowledged expert in Cloud Computing: Damian Flynn. Damian is an industry expert and author of the Cloud Chapters on two books: Microsoft Private Cloud Computing (Sybex), and Windows Server 2012 Hyper-V Installation and Configuration Guide (Sybex).

Virtual Machine Manager Example Service Templates

Travis Wright MSFT — Fri, 24 May 2013 01:47:51 GMT

Get your STEK (not steak)! The Service Template Example Kit is now available on the TechNet Gallery.

This set of System Center 2012 SP1 – Virtual Machine Manager service templates provide the necessary base for which you can create deployable and serviceable services for development or production. This gives fast deployment capabilities of development labs, line of business services and other custom applications.

In the downloaded compressed folder are the following files:

• 1-tier Single Server.Base v1.xml –Service Template of a single WS 2012 Data Center Server with no customizations. This is deployable.

• 1-tier Scalable Web Server.Base v1.xml – Service Template of a scalable WS 2012 Data Center web server. Includes features and roles for hosting basic .NET 4.5 web applications and NLB based load balancing.

• 2-tier Scalable Web Server w SQL.Base v1.xml – Based on the 1 tier scalable web application template with the addition of a SQL 2012 database tier.

• 3-tier Scalable Web Server w SQL.Base v1.xml – Based on the 2 tier scalable web application template with the addition of a middle web tier that is not scalable to act as a web service middle tier server.

• Standard_Scripts\Standard04062013.cr – Custom resource folder that includes all the stand scripts used by the above templates.

For an explanation of these examples and video on how to use click here. Please feel follow the blog series on this example and others here.

New Test Lab Guides for Virtual Machine Manager Now Available!

Travis Wright MSFT — Fri, 24 May 2013 01:30:07 GMT

We wanted to let you know that two Test Lab Guides for VMM (System Center 2012 SP1) are now available. The first one walks you through installing a VMM server, using the evaluation VHD for VMM. The second one tells how to use VMM to deploy a pair of virtual machines that can work together as a service. Here’s the link:

http://www.microsoft.com/download/details.aspx?id=38837

Logical Networks (Part III) – Network Isolation

Nigel Cain [MSFT] — Wed, 22 May 2013 00:36:53 GMT

In this blog, we begin to introduce multi-tenancy and isolation into the Logical Network design process we discussed in Part II, reviewing each of the Logical Networks we identified to determine whether or not you need to isolate groups of virtual machines and services that will use the same logical network. For reference, you can find part II at the following location:

http://blogs.technet.com/b/scvmm/archive/2013/04/29/logical-networks-part-ii-how-many-logical-networks-do-you-really-need.aspx

SC VMM 2012 SP1 allows you to isolate workloads using traditional VLAN/PVLANS, Network Virtualization and forwarding extensions that offers their own isolation method. In this post we review how to configure your Logical Network for “No Isolation” where there is no need to separate workloads and what you should do / how you should design your logical network solution when you want to use traditional VLAN isolation. We will cover PVLAN and Network Virtualization in a later blog post.

Look forward to your feedback and comments.

Nigel Cain & Damian Flynn

Step 3: Determine Isolation Requirements

To help explain this concept, let’s start with the basic assumption that computers that connect to and use the same network should be able to communicate with each other, and with routers that are used to connect different networks together should we wish to allow inter-network communication. This principle holds in most cases – indeed, where we find a business need to split off or otherwise isolate certain workloads either for security, to improve performance or simply to facilitate more effective control of network traffic, we essentially create a “new” network – either physically or via Virtual Networks (VLAN or PVLAN technology), place all of the appropriate computers and services on that network and update the network routing tables and security policy to facilitate inter-network communication, should that be required. This approach will be familiar to both Enterprise Customers and Service Providers, with the latter often using dedicated VLANs and PVLANs to isolate different customers from one another.

Logical Networks in SC VMM effectively model this behavior with resources that connect to a given logical network able to communicate with (any) other resource on that the same network, with inter-network communication handled via a router or gateway device. The problem for Service Providers (Hosters) is that following this general guideline, each customer invariably required their own Logical Network - an issue which historically led them to create and manage 100s if not 1,000s of Logical Networks within SC VMM. Given that each logical network needed to be associated with physical network adapters in one or more host computers, this solution impacted performance as well as increasing complexity and management overhead.

Virtual Machine (VM) Networks were introduced in VMM 2012 SP1 to address this particular issue; rather than connecting directly to a Logical Network, Virtual Machines in this release connect to a VM Network which acts an interface to a particular part of a Logical Network (as shown). Since VM networks are linked to the logical network, rather than associated with physical host computers, adding, deleting and making changes to these networks is greatly simplified over making changes to Logical Networks. Additionally, if Network Virtualization is enabled on the Logical Network as we discussed in Part I, multiple VM networks may be linked to a single Logical Network - removing the need for Service Providers to create separate Logical Networks for each of their customers.

If there is no need to separate or otherwise isolate network traffic from these machines, a single VM network linked to the Logical Network will be all that is required. As we discussed earlier, you will normally create multiple VM Networks when you are hosting workloads for multiple customers (tenants) on the same Logical Network, with each tenant needing to be isolated from and totally unaware of the existence of any others.

The diagram above shows each of these options and acts as a reference for the detailed discussion that follows. Note that the diagram is an extract from the Networking in Virtual Machine Manager Poster, available at the following location:

http://www.microsoft.com/en-us/download/details.aspx?id=37137

As the diagram suggests, you can’t mix and match different types of network isolation on the same Logical Network. It is not possible, for example, have some VM Networks configured isolated using VLAN/PVLAN technology with others using Network Virtualization. Should you need to use multiple approaches in your environment, you will need to return to step 2 above, Identify Networks with Different Purposes and define a separate Logical Network for each isolation method.

Note: There is a practical limit of ~2,000 tenants and ~4,000 VM Networks per VMM server. If you expect to approach either of these scale limitations you will most likely need to introduce additional VMM Servers and use Service Provider Foundation (SPF) to manage this environment. You should follow the same process (as above) with respect to identifying and creating logical and VM networks for each VMM server you deploy. You can find more information on SPF at the following location:

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

No Isolation

As mentioned above, isolation is only necessary in cases where a Logical Network will be used by multiple customers (tenants). Logical Networks created for corporate (internal) workloads, cloud infrastructure services and those that are dedicated to a specific customer are all single tenant, meaning that isolation is not required.

Also mentioned earlier, at least one VM Network is required for Logical Networks that will be accessed by virtual machines. If there is no need to isolate network traffic on the Logical Network, a single VM network configured for “No Isolation” (as shown below) is all that is required. The VM Network in this case simply acting as a “pass through” to the logical network.

Note: In VMM 2012, virtual machines were directly connected to Logical Networks. When customers using this release upgraded to SP1, VM Networks, configured for “no isolation”, were automatically created for each one of these Logical Networks. Virtual machines that existed prior to the upgrade were then connected to the (new) VM Network linked to their original Logical Network.

The result of this configuration that you establish a 1:1 mapping between the VM Network and the Logical Network, as shown below. As a result you can only have one VM Network configured for “No Isolation” per Logical Network. If virtual machines that connect to this VM Network should not be able to communicate with each other, you may need to consider breaking out an additional logical network to accommodate this requirement.

For those logical networks that will not be used by virtual machines, generally those dedicated to infrastructure services like storage and live migration traffic, clearly no VM Networks are required.

VLAN Isolation

Service Providers often use dedicated VLANs and PVLANs (which we will discuss later) to isolate different customers from one another. To reflect this network architecture in SC VMM 2012, administrators had to create Logical Network for each VLAN, a solution which often led to the creation of 100s if not 1,000s of Logical Networks - since each of these networks needed to be associated with physical hosts, the end result was degraded performance and greatly increased complexity.

As we discussed earlier, Virtual Machines in VMM 2012 SP1 connect to a VM Network which acts an interface to a particular Logical Network. Multiple VM networks may be linked to the same Logical Network if Network Virtualization is enabled, with each one of these VM Networks separated from and totally unaware of the existence of any of the others. The nature of these improvements means that instead of creating a separate Logical Network for each customer that will be isolated from others using VLAN technology, you should instead create a single Logical Network for all of these customers, configuring the properties of the network (as shown below) to specify that “sites within this logical network are not connected”.

You should allocate the VLAN to a Network site within the logical network. Multiple VLANS may be allocated to the same Network Site (as shown below)

Finally, VM Networks need to be created to allow customer virtual machines to connect to and use the Logical Network. VM Networks need to be created to allow virtual machines to connect to and use the Logical Network. Each VM Network you create is directly mapped to exactly one of the subnet VLANS that have been defined for a site in that Logical Network. As a result, you can only have as many VM Networks as you have subnet VLANS. The create VM Wizard (below) will display only those Network Sites that have not already been allocated to an existing VM Network.

The added benefit of having a VM Network on top of each VLAN is that you can use a name to clearly identify what it is used for and which customer has access to it. You can also apply access control to control/restrict who is able to use it.

Although you can manually choose which VLAN should be allocated to a VM Network, VMM also provides for automatic assignment. This is useful where customers are allocated a VLAN from a pool, rather than being given an assigned / specific VLAN. In these cases, a VLAN is randomly taken from the pool when you define a new VM Network and is returned and available for re-use when that VM Network is deleted. Note that once all of the available Network Sites have been allocated, no further VM Networks may be linked to this Logical Network until additional VLANS are added and/or some of the existing VM Networks are deleted.

To briefly summarize, create a single Logical Network, configured such that “sites within the logical network are not connected”, create sites and then specify the list of VLANs that exist in each site. Either create a VM Network to represent each VLAN and/or create VM Networks as and when needed, using automatic assignment to allocate a Network Site (VLAN) to that VM Network. The net result should be a 1:1 mapping between the VM Network and the VLAN, as shown below:

Note that that there are a number of limitations to using VLANs to isolate network traffic, most significantly the scalability limits –only 4095 VLANs are permitted per physical network, PVLANs (as discussed in our next blog) may be used to work around this limitation but at cost of increased complexity. The cost of management, level of complexity and the risk of error also increase significantly at high scale. These issues may not be of direct relevance to enterprise customers since, in general, they do not need to manage very large numbers of networks at this scale but are major consideration for Service Providers that provide hosted services to a large number of external customers.

VLAN isolation is expected to remain common practice in many enterprise deployments given its relative simplicity and ease of management at smaller scale. Service Providers (Hosters), however, given their need to manage a much larger number of networks, can be expected to use alternative isolation technologies to help workaround VLAN scale limitations.

Summary

If there is no need to separate or otherwise isolate network traffic from these machines, a single VM network linked to the Logical Network will be all that is required configured for “No Isolation”. If needed, SC VMM 2012 SP1 allows you to isolate workloads using either traditional VLAN/PVLANS or, if you are using Windows Server 2012 as your host operating system, you can choose to implement Network Virtualization. We covered VLAN isolation in this post. In part IV, we will discuss how to design and configure your logical networks for PVLAN and Network Virtualization.

I accidentally deleted the VMM self-signed certificate from the VMM server. Now what do I do?

J.C. Hornbeck — Tue, 14 May 2013 16:25:09 GMT

Vladimir Petrosyan | Support Escalation Engineer

Hey there again! This is Vladimir from the Virtual Machine Manager (VMM) team and today I have a really quick tip for you all that I found out myself recently working on an issue.

The issue is basically: “Hey, so I accidentally deleted the VMM self-signed certificate from the VMM server, and I cannot deploy VMs from the VM templates now. What do I do?”

Here is the quick solution:

1. Launch the VMM PowerShell on the Virtual Machine Manager server.

2. Type the following and press enter:

$credential = get-credential

3. Type the username and password that is a local admin on the VMM server.

4. Type the following and press enter:

Get-VMMManagedComputer -ComputerName "vmm2012sp1.contoso.com" | Register-SCVMMManagedComputer -Credential $credential

5. Ensure that the VMM job completes successfully under the Jobs tab in the VMM console.

Note: In my example above, vmm2012.contoso.com is the FQDN of the VMM server.

You can also use this technique to generate the VMM certificates for the hosts that VMM manages in cases where the expired/out-of-sync VMM certificate might be causing the issue (for example VMM jobs that fail with error 0x80072f0d).

I hope this helps!

Vladimir Petrosyan | Support Escalation Engineer | Microsoft GBS Management and Security Division

Get the latest System Center news on Facebook and Twitter:

Windows Intune: http://blogs.technet.com/b/windowsintune/
WSUS Support Team blog: http://blogs.technet.com/sus/
The AD RMS blog: http://blogs.technet.com/b/rmssupp/

App-V Team blog: http://blogs.technet.com/appv/
MED-V Team blog: http://blogs.technet.com/medv/
Server App-V Team blog: http://blogs.technet.com/b/serverappv

New Book About Virtual Machine Manager!

Travis Wright MSFT — Fri, 10 May 2013 20:58:16 GMT

One of our Microsoft MVPs, Alessandro Cardoso, wrote a great book on Virtual Machine Manager. Check it out! http://link.packtpub.com/POCsIQ

Application Management Track on Building Clouds

Kurt Scherer [MSFT] — Fri, 10 May 2013 17:20:00 GMT

Kurt Scherer from the VMM Team here, I wanted to bring attention to some awesome work around Service Templates in VMM. Over on the Building Clouds Blog, there have been a few recent posts that you should definitely check out.

First, Jim Britt has released a series of blog posts around the deployment of a SharePoint Farm using VMM Service Templates. You can check out the series here:

Application Management-Example-Deploying a Service to Your Private Cloud (Part 1)
Application Management-Example-Deploying a Service to Your Private Cloud (Part 2)
Application Management-Example-Deploying a Service to Your Private Cloud (Part 3)
Application Management-Example-Deploying a Service to Your Private Cloud (Part 4)

Additionally, some great work has been done by Shawn Gibbs on the same track. His post is available here:

Application Management – Service Templates, real reusable examples

So check out these posts and look for more to come on the Application Management Track section of the Building Clouds blog.

If you're new to the servicing concept, check out this new lab guide.

That’s all for now.