5

I have 2 hypervisors running. One is an ESXi 4, the other one a Hyper-V 2008 R2.

My question is: What is the cleanest and easiest way to clone a machine under each hypervisor without using any centralized management tool.

Thanks.

Alexandre Nizoux
  • 498
  • 1
  • 4
  • 15

3 Answers3

5

Windows Systems consider doing this:

  1. Create the "gold" machine, get everything like you want it.
  2. Use Sysprep: Run this command from from cmd.exe; sysprep -reseal
  3. Copy and paste the syspreped files for each new VM
  4. Boot, configure, and enjoy.

This is essentially what I do with ESX4 (I have about 100 Windows VMs across 4 servers and 2 SANs). Except on step 3 I convert the VM to a template, and deploy all new machines from the template.

Linux Systems consider this:

  1. Create the "gold" machine, get everything like you want it.
  2. Create a script that resets hostname, IP address, etc. (leave it on the system)
  3. Copy and paste the files for each new VM
  4. Boot, configure, and enjoy.

This is more of a process than a technology. But if you want something simple, this should be sufficient. Later when you feel that you need to start scaling, look into puppet or other automation tools that may help.

Works For Me(tm).

Joseph Kern
  • 9,809
  • 3
  • 31
  • 55
2

If your goal is without tools, just copy and paste the vhd and vmdk files and then create a new virtual machine that points to the new disks. If you want to clone all aspects of the machine, that's possible too, but more work.

However, there are a few things to consider. Snapshots will mean that there will be more than 1 file that consider. You'll need to copy the whole file tree and then merge the copies back into a single image.

Additionally, a clone can result in identical information on different machines. For example, IP, machine specific info, machine name, etc. If it's using Windows, you can use sysprep to generalize your machines after they are cloned. At the very minimum, make sure to change the IP and guest computer name.

You can also consider differencing disks. Switch your master to read-only and then create differencing disks that point to the master disk. Create a new machine that uses the differencing disk and you'll be set.

Scott Forsyth
  • 16,339
  • 3
  • 36
  • 55
  • I'd advise against differencing disks in any scenario other than lab testing or development (and perhaps not even there). What's the point of it? space saving? And in return you get a horrible single point of failure, more administration overhead and room for error and generally a mess. – V. Romanov Mar 08 '10 at 14:57
  • As a real-only file, it's not really more a single point of failure than any file on the disk. Look at all the files in your c:\windows\ folder that are single points of failure. :) Make your that you have good backups in either case. Check out the performance differences with differencing disks on Windows Server 2008 R2: http://tinyurl.com/yd8ex3s. The stigma with differencing disks is disappearing, and for good reason. There is room for error, I'll give you that, but someone that understands the file chain structure can do very well with differencing disks. – Scott Forsyth Mar 08 '10 at 21:27
0

I'd second Scott's answer of differencing disks - the master disk has more chance of being in RAM cache when reads are requested which CAN result in faster i/o (assuming you are disk bound, which many servers are). If you have plenty of disk i/o then the differencing disk will have some overhead.

As to it saving disk space - that's not the reason to use it in production. Caching is.