Run a Microsoft virtual lab on a Mac with Fusion and Hyper-V

An integrated Microsoft environment provides a lot of standard infrastructure for your project.  It also requires a certain amount of standard infrastructure irrespective of the size of the project. Active Directory is the most obvious example of this   Developers that want to test out Microsoft tools or sub-systems almost always need a multi-system environment because most  Microsoft products work best when bound to Active Directory, a tool that needs to run on its own system.  Virtualization can help here making it easy to build virtual labs , "personal clouds" or use something like Azure.

I've been working on a Microsoft project where all of our virtualization is done using Microsoft's Hyper-V.  This pushes me towards Hyper-V as my virtualization platform when sharing work with others on the team.  My most powerful laptop is my 16GB Quad-Core Macbook Pro.  Hyper-V doesn't run on OS/X so we can instead make use of a technique used by a lot of VMWare users.  Run a virtualized environment inside of another virtualized environment.  You can snapshot or backup and restore your entire environment by manipulating a single virtual drive.  All we need to do is to figure out how to run Hyper-V on a Mac.

Virtualized Lab Network Topology

You have two main networking choices when when it comes to a virtual lab on your desktop or laptop.  You can either use bridged or NAT networking. Bridging the virtual machines to your network putting them on the same backbone as your primary machine.  NAT networking isolates the virtual machines on their own network (VLAN) that is reachable from the host.

Bridge networking uses address space on the main network and makes the machines routable from other machines on the network.  Active Directory requires a fixed IP address so this system doesn't work well when the host machine moves from network to network or when multiple developers need to run their own virtual labs on the same network/project.


NAT networking creates a private VLAN that cannot be seen from any machine on the main network.  Machines on the VLAN do have outbound access to the main network including DNS.  Services on the VLAN virtual machines can be made visible through port forwarding.  The Port forwarding can be set up on the host machine to forward requests from the main network to the VLAN in the same way reverse proxy servers or firewalls forward to protected networks for "real" systems.

The isolated, non-routable nature of the network means that the fixed IP addresses can be used no matter what external network addresses are used.  It also means that each developer can have an identical private network with the same addresses without any conflicts.

I'm going to put the lab on a private network.  VMWare Fusion installs and uses network device VMNet8 to support NAT connections.  You can see that on your mac by running the command ifconfig in a terminal window.

DNS

VMWare Fusion's default DNS behavior is to make the DNS servers used by the (Mac) host available to the virtual machines.  This means the virtual machines can see the same hostnames that the MAC itself can.  It doesn't mean that the VMs can find each other or that anyone else can find them. 

Registering Virtual Machines in DNS 

Virtual machines can be added to a domain's DNS if running in bridged network mode because they are routable from the outside. The virtual machines cannot be added to global DNS if running on a private network via NAT because they are not routable from the public network.  

Virtual machines on the private LAN, in a NAT configuration, are visible to each other but are not registered by name even on the VLAN.  The usual way to handle this is to install a DNS server on the VLAN, assign fixed IPs on the VLAN and, register those VMs with that DNS server.  The private LAN VMs then all use that DNS server for the subdomain that is the VLAN.  Normally that DNS server also forwards or passes requests to the public server for machines not on the VLAN.

Active Directory and DNS

Microsoft servers are tied together through Active Directory. It acts as a controller for a standalone domain or subdomain.  That machine provides security authentication, common configuration, a common management point and acts as a DNS server for members of the domain. We need an AD machine in our virtual lab and we want all of the other machines to use that AD machine for AD and DNS.  We normally install and configure the AD Domain Controller and then tell all other machines that the DC is their DNS server.  They will then be able to bind to the AD domain and have DNS access for all VMs that are part of the domain.  We need to either manually configure each VM to point at this "non default" DNS server or we can configure the DNS returned by the Fusion DHCP server to point at  this AD/DNS server for DNS.  This makes it easy to configure the machines to bind to the doman.

Non-domain machines on the same private network will want name based access to the sub domain's DNS services.  They can either be manually configured to use the AD/DNS or you can configure the Mac's resolver to use the AD machine for that subdomain.  The non-domain machines will pick up DNS support for that AD domain when they request form the main Mac's DNS service.  It will route those requests to the AD controller.  

Virtual Machine Organization

There are a couple different ways of organizing the Virtual Machines and Virtual Disks (VMDKs/VHDs) when building a lab environment.  Network topology does not affect this decision.  Your can either run your virtual lab as a set of independent machines each rooted on the host file system or you can nest your virtual machines inside of a Hypervisor installed as a virtual machine.  The former is simpler but the latter a more powerful "virtual lab" or "private cloud" tool.

Independent VMs

This is the deployment diagram for a deployment where each virtual machine is in their own standalone VM.  Each VM is started and stopped manually though this could probably be scripted.  Each VM has its own virtual drive.


Virtual in Virtual

The virtual machines can all run inside a nested hypervisor.  This lets us simulate an isolated / firewalled network. People build whole sophisticated test networks using this technique. Nested virtual machines can use virtual drives nested inside the hypervisor's drive or they can use external SAN.

VMWare supports running ESXi inside of their other Hypervisors.  This is how the VMWare lab environments work.  ESXi acts like it does running on physical hardware while really running on virtual hardware. This diagram shows a deployed set of microsoft services running on the ESXi's Hypervisor all wrapped inside a Fusion virtual environment.  You can actually run multiple Hypervisors on top of the Fusion Hypervisor.



This is essentially the same story with the Fusion VM simulating a physical box that we deploy Windows Server on to.  That Windows Server thinks it is running on physical hardware that can run Hyper-V.  We can the deploy our app and SQL server inside the Hyper-V environment.  This is a great option for someone wanting to doing multi-machine Microsoft development on a Mac.




Making use of Fusion DHCPD.conf to Provide Static IP and DNS

AD requires a fixed IP address as does the private network DNS server. Application and data base servers are easier to configure and scale up if they have fixed IP address and are configured in DNS.  We can manually configure all the machines with static IP and DNS addresses.  Or, we can modify the DHCP server's dhcpd.conf file to have it provide the same functionality.  We just need to know the MAC addresses of each of the virtual machines that will be on our network. Here is a sample that shows how to configure a machine to have a fixed address and use a DNS server on the private network.


host AppServer1 {
    hardware ethernet 00:15:5D:90:84:00;
    fixed-address 172.16.144.101;
    option domain-name-servers 172.16.144.100;
}

Installation

Comments

Post a Comment

Popular posts from this blog

Installing the RNDIS driver on Windows 11 to use USB Raspberry Pi as network attached

Image
I do a lot of my development and configuration via ssh into my Raspberry Pi Zero over the RNDIS connection. Some models of the Raspberry PIs can be configured with  gadget drivers  that let the Raspberry pi emulate different devices when plugged into computers via USB. My favorite gadget  is the network profile that makes a Raspberry Pi look like an RNDIS-attached network device.  All types of network services travel over an RNDIS device without knowing it is a USB hardware connection. A Raspberry Pi shows up as a Remote NDIS (RNDIS) device when you plug the Pi into a PC or Mac via a USB cable. The gadget  in the Windows Device Manager picture shows this RNDIS Gadget connectivity between a Windows machine and a Raspberry Pi. The Problem Windows 11 and Windows 10 no longer auto-installs the RNDIS driver that makes magic happen. Windows recognizes that the Raspberry Pi is some type of generic USB COM device. Manually running W indows Update  or  Update Driver  does  not  install the RNDI
Read more

Understanding your WSL2 RAM and swap - Changing the default 50%-25%

Image
The Windows Subsystem for Linux operates as a virtual machine that can dynamically grow the amount of RAM to a maximum set at startup time.  Microsoft sets a default maximum RAM available to 50% of the physical memory and a swap-space that is 1/4 of the maximum WSL RAM.  You can scale those numbers up or down to allocate more or less RAM to the Linux instance. The first drawing shows the default WSL memory and swap space sizing. The images below show a developer machine that is running a dev environment in WSL2 and Docker Desktop.  Docker Desktop has two of its own WSL modules that need to be accounted for.  You can see that the memory would actually be oversubscribed, 3 x 50% if every VM used its maximum memory.  The actual amount of memory used is significantly smaller allowing every piece to fit. Click to Enlarge The second drawing shows the memory allocation on my 64GB laptop. WSL Linux defaults to a maximum RAM size of 5
Read more

Almost PaaS Document Parsing with Tika and AWS Elastic Beanstalk

Image
The Apache Tika project provides a  library capable of parsing and extracting data and meta data from over 1000 file types.  Tika is available as a single jar file that can be included inside applications or as a deployable jar file that runs Tika as a standalone service. This blog describes deploying the Tika jar as an auto-scale service in Amazon AWS Elastic Beanstalk.  I selected Elastic Beanstalk because it supports jar based deployments without any real Infrastructure configuration. Elastic Beanstalk auto-scale should take care of scaling up and down for for the number of requests you get. Tika parses documents and extracts their text completely in memory. Tika was deployed for this blog using EC2 t2.micro instances available in the AWS free tier. t2.micro VMs are 1GB which means that you are restricted in document complexity and size. You would size your instances appropriately for your largest documents.   Preconditions An AWS account. AWS access id and secret key.
Read more