Page 1 of 2

HOWTO: Cloning a complete VM (not only the VDI)

Posted: 14. Sep 2008, 15:21
by shmuelakam
Tutorial: Cloning a complete VM (not only the VDI)

Having found many tutorials on cloning just the VDI, I played around a bit and managed to duplicate the entire VM. The following procedure worked fine for me (numerous times). I've done this using VirtualBox 2.0.2 (and 1.6.6) on a Win-XP Host, with an Ubuntu Guest (not that this should matter, as the steps should remain the same).

A caveat: My need was to create a number of initially identical new VMs, so I've never done this for an older VM that has already had snapshots taken. From what I've seen, the changes creating a snapshot create in the VM configuration file would make the following procedure more difficult.

Lets say you want to duplicate ("clone") your fully installed, configured and otherwise customized BaseLine VM, to a new VM called Other.

1) Clone the VDI:
While in the VDI directory, enter from the command line -

Code: Select all

VBoxManage clonevdi BaseLine.VDI Other.VDI
2) Create empty VM configuration for clone:
Doing this from the command line is fast and simple –

Code: Select all

VBoxManage createvm -register -name Other
This creates the base directory and a mostly empty xml configuration file. More importantly, this registers the VM, so that it will appear in the GUI tool list. VBoxManage is kind enough to write the UUID of the new VM to the screen. We'll need it shortly, so you might want to save it somewhere.

3) Copy the existing VM configuration:
This is done by replacing the empty configuration file with the BaseLine configuration. While in the Machines directory, enter from the command line -

Code: Select all

del Other\Other.xml
copy BaseLine\BaseLine.xml Other\Other.xml
4) Modify the Other configuration file:
Using text-editor, make critical changes to two lines of the Other.xml file:
a) Changing the UUID and name: At the very beginning of the file, in the Machine field, change the value of uuid attribute to the UUID created above (be careful to replace only actual value, leaving the "{" and "}" around it). Also change the name value to "Other".
b)At the bottom of the file, completely remove the hard-disk description line HardDiskAttachment. If you don't do this, you will have two VMs referring to the same VDI, and VirtualBox won't let you use the Other VM, marking it inaccessible, because the VDI it uses is already in use.

5) Finish the job:
a) Using the GUI tool, open the Virtual disk Manager (under File menu), and Add the Other.VDI to the list.
b) Now configure the Other VM - Set the Hard-disk to point to the Other.VDI.
c) If your VM had network adapters, you'll need to go into their properties, and Generate a new MAC address.

That's it! Easier than Pie, if you ask me.

Of course you'll have to start-up your VM and make any additional internal changes such as IP address (if fixed) and hostname, or whatever more your specific Guest OS requires.

I'm a complete nube at this, so if there is an easier way, or if I made any gross mistakes, feel free to correct me. If this is inappropriate, or you would rather people didn't do it, feel free to remove it.

I'm stupid

Posted: 24. Sep 2008, 06:32
by jimgo
Ok, I am not trying to be stupid.
I can normally follow instructions, but in the case of the creating a clone of a virtual machine I am simply stuck, as I have seen a few posts that tell you to "

1) Clone the VDI:
While in the VDI directory, enter from the command line -
Code:
VBoxManage clonevdi BaseLine.VDI Other.VDI"

Is this instruction relevant for Winxp - I have tried to do this from the dosbox, (cmd) but it does not recognize vboxmanage command. How does one do this in Winxp?

Sorry I am sure this is simple answer.

Follow the PATH

Posted: 24. Sep 2008, 11:22
by shmuelakam
If it doesn't "recognize" the vboxmanage command, this means that it can't find it in the current path. On Win-XP, the default installation directory for VBox is: C:\Program Files\Sun\xVM VirtualBox\

So either write that out explicitly at beginning of the command, or add the directory to the PATH system variable, like I did.

Posted: 24. Sep 2008, 16:27
by stootch
Be careful with this how-to if you use guests connected to host's network interface(s). You'll simply duplicate MAC addresses of NICs in your LAN which will put you into big trouble.

Posted: 24. Sep 2008, 19:51
by Sasquatch
stootch wrote:Be careful with this how-to if you use guests connected to host's network interface(s). You'll simply duplicate MAC addresses of NICs in your LAN which will put you into big trouble.
Good call. Best thing to do before starting the VM is to hit the generate button.

Actually

Posted: 24. Sep 2008, 21:22
by shmuelakam
I covered that at the very end - 5-c. So, yeah! You need new MAC addresses.

Posted: 25. Sep 2008, 14:35
by mpack
stootch wrote:Be careful with this how-to if you use guests connected to host's network interface(s). You'll simply duplicate MAC addresses of NICs in your LAN which will put you into big trouble.
Can you or someone else explain this a bit further? I thought every VM created by VBox had its own MAC addresses? (either automatically generated or manually typed in by the user). Also don't all VMs "use host network interfaces"? How else do they get internet access?

If you copy the VM's xml file you will now have two VMs with the same MAC as each other (but not the same as the host NIC). That's a problem if you try to run those two VMs at the same time. Is this the "trouble" that was referred to?

Posted: 25. Sep 2008, 19:40
by stootch
mpack wrote:Can you or someone else explain this a bit further? I thought every VM created by VBox had its own MAC addresses? (either automatically generated or manually typed in by the user).
That's exactly the point. New VM created in point 2 of the how-to is discarded and replaced by old one, thus cloning its whole configuration (MAC addresses included :))
mpack wrote:Also don't all VMs "use host network interfaces"? How else do they get internet access?
I meant "hostif" mode of virtualized NIC. But I'm afraid "nat" mode would also be affected.
mpack wrote:If you copy the VM's xml file you will now have two VMs with the same MAC as each other (but not the same as the host NIC). That's a problem if you try to run those two VMs at the same time. Is this the "trouble" that was referred to?
This is low-level network stuff. At some layer of network transport, instead of IP addressing and packets, frames and hardware addresses come into the game. All network equipment uses MACs to determine source and destination of the data. Imagine telephone network in which few subscribers have the same phone number.

Posted: 25. Sep 2008, 20:35
by mpack
stootch wrote:All network equipment uses MACs to determine source and destination of the data. Imagine telephone network in which few subscribers have the same phone number.
Hi - thanks for the response. I'm actually familiar with how addresses are used in network protocols. In the past I've designed my own HDLC-like protocol for embedded devices, and I once even even started writing my own TCP stack - but never finished it.

My question was specifically on what you said about MAC copying: it seemed to me that you might be saying that the cloned VM somehow gets a copy of the hosts MAC - that is what I thought your wording suggested - and that of course would always be a problem. Is that really what you meant, or did you simply mean that original VM and its clone both had the same MAC? (in that case, only a problem if you run both at same time).

Posted: 26. Sep 2008, 07:37
by stootch
Mpack,

Of course the latter one scenario (two VMs with identical MACs).

Posted: 26. Sep 2008, 14:29
by mpack
stootch wrote:Of course the latter one scenario (two VMs with identical MACs).
Thanks for responding again. I wasn't just being pedantic - I use a method similar to this howto for cloning VMs, so I just wanted to make sure I wasn't making some awful mistake.

Now that I know we are not talking at cross purposes, I can tell you that I explicitly ensure that my cloned VM does have an duplicate MAC! In my book, the whole point of a clone is that the hardware is identical - the only changes would be which app versions are installed, etc, inside the box. From that initial assumption I can then choose what hardware changes to make, if any. Of course I have no intention of running clones at the same time.

Posted: 10. Oct 2008, 15:32
by JFQueralt
Hi there.

Does anybody know if there is a way to block settings for a coned VM?

I want to distribute few VMs across my students but would like them to not mess with the network and other nasty things they could do.
I want to give them a closed config and that´s all so far.

Thanks in advance.

Jean

Posted: 10. Oct 2008, 19:37
by Sasquatch
JFQueralt wrote:Hi there.

Does anybody know if there is a way to block settings for a coned VM?

I want to distribute few VMs across my students but would like them to not mess with the network and other nasty things they could do.
I want to give them a closed config and that´s all so far.

Thanks in advance.

Jean
You could make the file readonly and full control for Administrator, but less for the students user group. However, this is only for the machine it runs on. This does not mean they can't copy the file to their own machine or external drive for personal use.

Posted: 11. Oct 2008, 02:15
by virtuoso
There are so many steps involved with cloning a VDI!

I wish I could just right-click on an existing VDI and hit the "Clone..." button! :(

Posted: 11. Oct 2008, 13:01
by Sasquatch
virtuoso wrote:There are so many steps involved with cloning a VDI!

I wish I could just right-click on an existing VDI and hit the "Clone..." button! :(
Why not add that? You can create custom context menu items in Windows, and I'm sure you can do the same for Linux and other OSes.