Detecting An Improperly Cloned VM

  • One of our production servers (a SQL Server host) was "cloned" to make a secondary test environment. The source server is a virtual machine (VMWare vSphere environment) joined to a domain and with a static IP address.

    When the cloned VM was powered on, the virtual network adapter was enabled. The computer name was not changed. Neither was the IP address. Somehow, those two servers with the same DNS name and IP address co-existed on the same domain for several days--maybe as much as a week.

    Each server was running identical SQL Agent backup jobs. Backup jobs for exactly one of the two servers would fail every time. The email alert I received referenced the DNS name of the server, so I don't know which server "won". I now have up to a week of db backups that are inconsistent at best, and possibly worthless. I have to compare data from both servers and try to determine if sql transactions intended for the source and transactions intended for the clone were applied to both servers or one server. If it was one server, was it consistently the same server? I fear there may be a "cross-contamination" mess to clean up.

    Whether it's carelessness or ignorance, people make mistakes. I can accept this. So let's assume it might happen again. I know how to fix the problem. But how do I detect it?

    Note: I am not looking for instructions or advice on how to clone a VM. I am not the one given that task. I'm wondering if there is a way to quickly (or immediately) detect when two computers/workstations/VM's have the same DNS name and/or IP address.

  • Dave Mason (11/20/2014)


    One of our production servers (a SQL Server host) was "cloned" to make a secondary test environment. The source server is a virtual machine (VMWare vSphere environment) joined to a domain and with a static IP address.

    When the cloned VM was powered on, the virtual network adapter was enabled. The computer name was not changed. Neither was the IP address. Somehow, those two servers with the same DNS name and IP address co-existed on the same domain for several days--maybe as much as a week.

    Each server was running identical SQL Agent backup jobs. Backup jobs for exactly one of the two servers would fail every time. The email alert I received referenced the DNS name of the server, so I don't know which server "won". I now have up to a week of db backups that are inconsistent at best, and possibly worthless. I have to compare data from both servers and try to determine if sql transactions intended for the source and transactions intended for the clone were applied to both servers or one server. If it was one server, was it consistently the same server? I fear there may be a "cross-contamination" mess to clean up.

    Whether it's carelessness or ignorance, people make mistakes. I can accept this. So let's assume it might happen again. I know how to fix the problem. But how do I detect it?

    Note: I am not looking for instructions or advice on how to clone a VM. I am not the one given that task. I'm wondering if there is a way to quickly (or immediately) detect when two computers/workstations/VM's have the same DNS name and/or IP address.

    I don't think so. Unless you scan your IPs, which may NOT be ok in your environment as that's why hackers usually do when getting into a network. You basically will have to wait until a VM gets out of network due a duplicate IP.

    A workaround though, would be checking the VM SID, and that's way less intrusive and actually easy. I did that few months ago and that's how I detected improperly cloned machines in my environment. I can't remember the tool I use, but was a command prompt type of tool. If the SID is the same, chances are high that the IPs are also the same.

  • I decided to run a "check" at startup that would try to determine if the SQL instance had been cloned.

    TLDR: Hard-code the SQL host machine name and domain in a stored proc and compare those values to SERVERPROPERTY(N'MachineName') and DEFAULT_DOMAIN(). Do something drastic if the values don't match.

    If anyone is interested, I blogged about it: SQL Server: Attack Of The Clones

Viewing 3 posts - 1 through 2 (of 2 total)

You must be logged in to reply to this topic. Login to reply