In a recent conversation, a topic came up that has manifested itself a number of different ways to me in my IT career. The main issue was that one organization required a change order to migrate a virtual machine from one host to another. This would be leveraging a feature such as VMware’s vMotion technology that will migrate the active state of a running virtual machine from one ESX(i) host to another, leveraging shared storage with no downtime. In my professional experience, I’ve never had a situation where a feature such as vMotion cannot be run on a production virtual machine.
The issue at the root of that discussion is what constitutes a “change” in the IT environment, however. There are changes in the virtual machine during an event like that, such as it (presumably) now has more CPU or memory resources to work with on the new ESX(i) host. There may be an ARP table update as the virtual machine would now be on a new switch port. Finally, that same virtual machine would be inventoried on a new ESXi host; within the same cluster. These “changes” are academic at best, but in the scheme of traditional IT practices; the core running configuration of the virtual machine has not changed. Other unchanged attributes of the virtual machine include operating system configuration, TCP/IP address and other network attributes in the guest virtual machine, DNS name, configured memory and processor resources, and finally the application inventory.
The virtual machine migration example is repeated en masse in today’s IT landscape. Other events can include:
- putting a VMware ESX(i) host in maintenance mode
- adding a DNS server to a production server’s IP configuration for additional resolution
- resetting a tape drive out of production timeframes
- replacing a failed hard drive on a RAID array for a rebuild operation
- deleting a stale user profile on a server
- performing a dynamic expand of a virtual machine disk of a running virtual machine to address free space issues.
There are scores and scores of situations like this that aren’t really changes to a production workload’s running integrity, but are in fact functions of the technologies we have today. What do we do about this gap?
In my experience, I approached these challenges with a mechanism I referred to as a reserved administrative function. Basically, these are operational practices that are regular, predictable and within the capabilities of the technologies we approve for use. If these operational practices were identified to be within the realm of a reserved administrative function, they did not need prior approval through a traditional change management board. This doesn’t necessarily mean they didn’t need approval; it could be a peer review or management decision. Further, tracking must be met. This can be in the form of a system log, support case, or a physical log.
How do you approach changes in the new era of IT technologies? Am I off base with the concept of reserved administrative functions? Share your comments below.
Rick Vanover is a software strategy specialist for Veeam Software, based in Columbus, Ohio. Rick has years of IT experience and focuses on virtualization, Windows-based server administration, and system hardware.