TimurD - Fotolia

Manage Learn to apply best practices and optimize your operations.

Micro VMs can present unique management challenges

The haphazard deployment of micro VMs can eventually lead to issues ranging from IP address depletion to serious performance problems resulting from extreme resource contention.

In many ways, a micro VM is just like any other VM, except smaller. Like with other VMs, IT administrators allocate resources such as CPU, memory and storage to micro VMs and manage them using tools such as vCenter Server or System Center Virtual Machine Manager.

However, in spite of their similarities to other VMs, micro VMs can sometimes introduce hidden management challenges.

Some of these management challenges stem from creating large numbers of tiny VMs over time. Because micro VMs are so small, it's easy to regard them as being insignificant in terms of their effect on the virtualization infrastructure.

Keep the hypervisor's VM limit in mind

One potential problem that can result from the accumulation of a large number of tiny VMs is exceeding the hypervisor's VM limit or perhaps exceeding the available software licenses.

Modern hypervisors tend to support a large number of VMs, but reaching these limits is hardly unthinkable, especially in the context of tiny VMs. For example, Hyper-V has a limit of 1024 running VMs per host. This limit was much lower in some of the earlier versions of Hyper-V. For example, Windows Server 2008 R2 had a limit of 384 running VMs per host.

Even if an organization doesn't create enough tiny VMs to exceed the hypervisor's limits, creating a large number of micro VMs can create other problems. One such problem is that of IP address depletion. A Dynamic Host Configuration Protocol (DHCP) scope provides a finite number of IP addresses, and VMs can quickly claim all of a scope's available addresses if admins create VMs without regard for the IP address pool.

Even if an organization doesn't create enough tiny VMs to exceed the hypervisor's limits, creating a large number of micro VMs can create other problems.

It's worth noting that the large-scale use of small, temporary VMs can greatly accelerate IP address consumption. A DHCP server leases IP addresses to a client for a specific period of time, often in range of days to weeks. If an admin brings a temporary VM online and then quickly terminates it, the DHCP server usually marks the VM's IP address as unavailable until the lease period expires, even if the VM no longer exists.

Avoid excessive resource contention

Another problem that can stem from the large-scale use of micro VMs is excessive resource contention. Because micro VMs are so small, they are commonly regarded as consuming miniscule amounts of system resources. However, a VM's size actually has very little to do with its resource consumption.

As a somewhat extreme example, consider the stress test tool, HeavyLoad. The 64-bit version of HeavyLoad is less than 10 MB in size, and yet the tool can consume immense amounts of system resources. Although it's unlikely that an organization would run HeavyLoad on a production VM -- aside from maybe doing some initial testing -- the tool clearly illustrates that even a tiny application can consume large amounts of CPU, memory, storage or network resources.

The other problem that stems from treating micro VM resource consumption as insignificant is that even if the VMs really do consume miniscule amounts of system resources, large numbers of these tiny VMs can collectively consume enough resources to overwhelm the host.

Another way of thinking about this concept is that although a drop of water might be insignificant, many drops of water can collectively form an ocean.

Dig Deeper on Capacity planning for virtualization

Join the conversation

2 comments

Send me notifications when other members comment.

Please create a username to comment.

How do you ensure a micro VM deployment doesn't get out of hand?
Cancel
The points raised in this article are debatable.
1. IP address depletion is unlikely as you are primarily using private IP address rages with public IP addresses being mapped to a load balancer.
2. I would agree that managing networking with an increasing volume of vm's would challenging, therefore some form of SDN is required in any high rate of change environment. An enterprise class SDN like NSX will manage an IP pool and for certain use cases, the NAT capability will enable duplicate IP addresses to exist on the network as vm's are known by object ID.
3. Even the mentioned hyper-V's 1024 VM per host is plenty compared to an average consolidation of 40 - 80 VM's per host today.
4. Host capacity today is not managed by the number of VM's per host, but rather the overall host utilization. Why would managing spikes be harder with micro vm's? Essentially, you are not wasting as much resource on duplicated OS functions, therefore there is more resource for your applications, but this in itself does not create utilization spikes.

With all the above mentioned, there is a lot of benefit to using containers beyond a finer point of isolation and for the foreseeable future both vm's and containers are likely to co-exist.
Cancel

-ADS BY GOOGLE

SearchVMware

SearchWindowsServer

SearchCloudComputing

SearchVirtualDesktop

SearchDataCenter

Close