SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


Detecting An Improperly Cloned VM


Detecting An Improperly Cloned VM

Author
Message
Dave Mason
Dave Mason
SSCrazy
SSCrazy (2.4K reputation)SSCrazy (2.4K reputation)SSCrazy (2.4K reputation)SSCrazy (2.4K reputation)SSCrazy (2.4K reputation)SSCrazy (2.4K reputation)SSCrazy (2.4K reputation)SSCrazy (2.4K reputation)

Group: General Forum Members
Points: 2435 Visits: 943
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 MasonSeminole County, FL
sql-lover
sql-lover
SSCoach
SSCoach (16K reputation)SSCoach (16K reputation)SSCoach (16K reputation)SSCoach (16K reputation)SSCoach (16K reputation)SSCoach (16K reputation)SSCoach (16K reputation)SSCoach (16K reputation)

Group: General Forum Members
Points: 16867 Visits: 1930
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.
Dave Mason
Dave Mason
SSCrazy
SSCrazy (2.4K reputation)SSCrazy (2.4K reputation)SSCrazy (2.4K reputation)SSCrazy (2.4K reputation)SSCrazy (2.4K reputation)SSCrazy (2.4K reputation)SSCrazy (2.4K reputation)SSCrazy (2.4K reputation)

Group: General Forum Members
Points: 2435 Visits: 943
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

Dave MasonSeminole County, FL
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum








































































































































































SQLServerCentral


Search