Virtual Machines - The Challenge of Vision

Virtual Machines - The Challenge of Vision

Summary: Virtualization has the potential of offering tremendous advantages over physical environments, but in the move to virtual, the organization often lost some things it took for granted. One of those things is clarity of what is going on, where, and with whom.


Virtualization has the potential of offering tremendous advantages over physical environments, but in the move to virtual, the organization often lost some things it took for granted. One of those things is clarity of what is going on, where, and with whom.

What’s WHAT?

In a physical environment, such as a typical datacenter, all of the systems, network devices, storage devices and even power supplies and air conditioning units are carefully organized and labeled with their IP addresses, with their network names, and often the application it is supporting.

The midrange systems from IBM, Sun or Hewlett-Packard are over in the corner running manufacturing or billing applications, the mainframe that sitting in the center of the datacenter is a whiz at processing thousands upon thousands of transactions, and a racks of industry standard (x86) machines are supporting Web-based applications and the organization’s collaborative systems.

Finding each of these systems in the datacenter is relatively easy. Traditionally, it has also been easy to learn what each of these systems is doing at any given moment. Quite often datacenter resources are grouped according to the application they’re supporting.

As organizations began moving functions from physical systems to virtual systems they ran straight into a new problem. Virtual machines are ephemeral. They can be generated, provisioned with the appropriate software and put into production very rapidly. They can be halted and deleted when they no longer are needed. No labels define their location or presence.

IT executives are increasingly facing the fact that there really is no good way of telling what virtualized applications are running, where they are located at any given moment, which business unit owns them, when they were created, when they should expire, which physical resources they are using and whole host of other questions. It is no longer easy to determine either what physical systems are doing or, more importantly, not doing.

What’s Where?

Technology, such as VMware’s Vmotion, Citrix/XenSource’s Xenmotion, and many orchestration products, allow organizations to move virtual systems about at will. Knowing where everything is on a moment by moment basis can be quite challenging.

If an organization needs to maintain an audit trail of where the computing was done, where the data is and other important data points, they increasingly face a very difficult challenge. Complying with some regulations may be impossible unless there is a structured, well-defined way to track everything. Organizations simply must have a trail of their motion, a history, or a “chain of custody” as they transfer from place to place and from test beds to actual production.

What's your plan?

What tools are in use in your organization's datacenter to help discover, track, and manage virtual resources? Who is responsible for managing these resources?

Topics: Data Centers, Hardware, Storage, Virtualization


Daniel Kusnetzky, a reformed software engineer and product manager, founded Kusnetzky Group LLC in 2006. He's literally written the book on virtualization and often comments on cloud computing, mobility and systems software. In his spare time, he's also the managing partner of Lux Sonus LLC, an investment firm.

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • I don't understand what the problem is

    It's just a simple matter of applying standard approaches to data management.

    The physical machines, the virtual machines and the software running on them are all data. Therefore the relations between them can be easily defined (and presumably suitable constraints to prevent you deleting a virtual machine that's running important software).

    Understanding a many to many relationship between physical machines and virtual machines shouldn't be difficult at all.

    I suspect the poor quality of the systems software at present makes if far more difficult than it should be.
    • I agree...

      How hard is it to use naming standards for host

      3 or 4 chars for owning group
      3 or 4 chars for box function
      2 digits if there will be multiples with the same function
      example web servers


      AAI = Advanced Application Integration
      WEB = Web Server
      12 = The 12th web server.

      As far as location (which VM Server) a simple IP address map will work 10.10.x.x is VM Server A 10.11.x.x VM Server B
    • I agree

      Besides that, if you can count with a good CMDB and Configuration Management Process it's easy to know essential information about machines, virtual or not, and the systems running in.
      Really don't mather in wich host the machine is now running, but the host or farm of hosts.
  • I am sorry but I don't see the problem either.

    Virtual machines are no more difficult to track than large data centers of distributed servers and applications have ever been.

    We use a simple 2 tier naming convention where physical devices are named by their location and function, and virtual devices are named by the business unit and application/service.

    For example:
    USALVM01 (USA Alabama VMware 1)
    - ITDC01 (Information Technology Domain Controller 1)
    - ITDNS (Information Technology DNS)
    - ITMAIL01 (Information Technology Exchange Server 1)

    USALVM02 (USA Alabama VMware 2)
    - ITDC02 (Information Technology Domain Controller 2)
    - ITDHCP (Information Technology DHCP)
    - ITMAIL02 (Information Technology Exchange Server 2)

    USALVM03 (USA Alabama VMware 3)
    - FINSQLDEV (Finance SQL database Development)
    - FINSQLPRD (Finance SQL database Production)
    - FINSQLRPT (Finance SQL database Reporting)

    USALVM04 (USA Alabama VMware 4)
    - MKTWEBDEV (Marketing Web Development)
    - MKTWEBSTAGE (Marketing Web Content Staging)
    - MKTWEBPROD1 (Marketing Web Server Farm Unit 1)
    - MKTWEBPROD2 (Marketing Web Server Farm Unit 2)
    - MKTWEBPROD3 (Marketing Web Server Farm Unit 3)

    ... and so on for the remaining dozen or so physical ESX host systems. When virtual devices are moved from one machine to another via VMotion, their names move with them making it easy to track what is running where. A simple database containing the departmental contact names and application life-cycle information makes it easy to administer.

    Frankly, it looks to me like a bit of planning and some documentation would resolve your problems.

    Just my $0.02 USD, and your opinion may vary...

  • RE: Virtual Machines - The Challenge of Vision

    When I need a Virtual Machine, I assign it an IP, Name of Computer, and date/revision number as the NAME of the VM.
    This save me the hassle of what it is running, what services it is providing, and allows me with a glance to see what is available.
    Simple, I would guess.
    If I needed more, I would just do an inventory of the running system and then store that as a reference material for the VM's. This could provide an automated lookup if I then hooked this data into a system that handle queries of the data.
  • Keeping tracking of the inventory is the issue?

    Yes, there seems to be a little probel of keeping track of the inventory but if the team/dept is self-disciplined and keep 'just enough' documentation (or tools like wiki) could help keeping track of the stuff that goes on VM boxes.
  • RE: Virtual Machines - The Challenge of Vision

    The most interesting thing on this article is
    not said out loud: It is very easy to hide a VM.
    For years, it was relatively easy to keep a pet
    server doing little things for the guys at the
    IT department, but now with VMs the
    thing is really scary. For example, an angry
    employee can deploy an entire computer aimed to
    breach the system after he is fired.
  • It works

    At our Data Center we have 22 virtual machines with the software from Microsoft, 6 of them are at production environment the others are for development and testing purposes.

    Finally our servers are been used more than 4-5%!

    The other important thing is that the Software Requirements always says: "Easy! Windows, IIS and SQL Server, nothing else!" but when you actually make the deployment often two system can share the same server.