Server Virtualization Blog - A SearchServerVirtualization.com blog

Server Virtualization Blog:

 

A SearchServerVirtualization.com blog


A server virtualization blog covering virtual machine (VM) management and administration, VMware, Xen, Microsoft, server consolidation and hardware, backup and disaster recovery, VDI (virtual desktop infrastructure) and more.

When not to treat VMs like physical servers

A general rule of thumb in virtual environments is to always treat virtual machines the same as you would physical servers. While this rule holds true in many cases, IT administrators should be aware of some exceptions to this rule. Let’s go over some reasons that you would not treat your virtual machines like physical servers:

  • Patching – You should apply all the same operating system and application patches to a virtual machine as you would a physical server. However it is best to stagger your patch deployments so you do not patch and restart all of your virtual machines at the same time. If you did this concurrently you can cause excessive resource utilization on your host servers which could impact other virtual machines running on the host.
  • Securing – Secure the virtual machine operating system as you would physical servers, in addition you should ensure that you have proper security setup on the host server’s management console that allows access to the VM as well as on the virtual machine files located on the host server’s disk system. It does no good to have tight security inside your VM and have weak security outside.
  • System Monitoring – This is one area that can be very different for virtual servers. There is no need to monitor virtual machine hardware, if you have converted physical servers to virtual machines you should make sure you un-install any hardware management agents from them. In addition virtual machines boot much faster then physical servers. Because of this, many monitoring systems will not detect server re-boots because the boot process happens quicker then the monitoring interval. You may find that you need to adjust your polling interval for virtual servers so you can detect the faster re-boots.
  • Performance Monitoring – Another area that is very different from physical servers. Traditional operating system performance reporting tools are often inaccurate when used on virtual machines because they are unaware of the virtualization layer and the underlying physical hardware. You should always use virtual server specific reporting tools to accurately measure performance on virtual machines.
  • Anti-virus – Make sure you install anti-virus software on all your virtual machines the same as physical servers. Again one thing to be careful of is to stagger any on-demand scans and definition updates as to not overwhelm the host server. Having all your VMs running a full scan at the same time can completely bog down a host server.
  • Backups – It’s OK to backup your virtual machines using traditional operating system backup agents. Always make sure you do not backup too many VMs on a single host at the same time. There are more efficient ways to perform backups in a virtual environment that you may look into to either complement or replace traditional backup methods.
  • Disk defragging – You should periodically defrag virtual machine disks using traditional operating system tools for maximum performance. However be careful not to defrag a VM that has a snapshot running, doing this can cause the snapshots rapidly grow in size and degrade host performance. As usual do not defrag more then one VM on a host at a single time because of all the excessive disk activity that is causes.

Be careful not to do too many of the same operations concurrently. With physical servers, only a single server is effected, but in virtual environments many other servers running on a host server can be impacted.

2 Comments »

  1. Eric,

    This is a nice concise checklist of the key things to take into consideration with VMs all branching from the base conclusion that one should not impact the underlying physical hardware too much.

    With off-the-shelf patch management software (partchlink et al) this is tough to do - have you any advice about how to configure or better still what automation tools to use for patch management?

    Thanks

    Steve

    Comment by Steve O'Donnell — July 26, 2008 @ 10:36 am

  2. Hi Steve,

    I’m not aware of a specific product for patching virtual machines. VMware now has an Update Manager plug-in to VirtualCenter for patching ESX hosts and VMs but I don’t think it has the capability to stagger patch deployments. If you are using Microsoft WSUS you can create multiple group policies with different update dates/times and then assign them to groups of servers. For example create 3 group policies and assign 1/3 of your VM’s to each one like below.

    Policy 1 - Sun, Thu 3:00am
    Policy 2 - Mon, Fri 3:00am
    Policy 3 - Tue, Sat 3:00am

    I’m not sure about other patching products like BigFix and Patchlink but they may also have controls that let you throttle and stagger your patch deployment.

    Eric

    Comment by Eric Siebert — July 28, 2008 @ 3:44 pm

Leave a comment