# migrate a physical FreeBSD into vSphere



## ccc (Sep 18, 2012)

Hi

What is the best way to migrate already existing physical FreeBSD 8.2-RELEASE server into ESX 3.X or vSphere 5.X as a guest VM, without losing  data?


----------



## wblock@ (Sep 18, 2012)

Use a LiveCD like the FreeBSD install disk or mfsBSD to set up the disks on the target system.  Or just install FreeBSD to it.  That has the added benefit of making sure the new system has bootcode set up to boot.  Then use dump(8)/restore(8) or zfs(8) send/receive (depending on the original system) to copy all the data from the original system onto the target.  This can be done over ssh(1) without additional media: Backup Options For FreeBSD.


----------



## throAU (Sep 21, 2012)

ccc said:
			
		

> Hi
> 
> What is the best way to migrate already existing physical FreeBSD 8.2-RELEASE server into ESX 3.X or vSphere 5.X as a guest VM, without losing  data?



VMware do a cold clone CD, if you have a VMware license you should be able to download it from their website.  I'm not sure if it is available with a free license or not, though I suspect it is.


Process:  Boot cold clone CD, connect it to vSphere server (or ESX server?), and basically follow the bouncing ball to create a new VM and copy the existing physical disks over.

Once copied, shut down the physical machine, pull out/label network cable (telling others not to plug it in), and test your VM works.  You may need to adjust network adapters/firewall rules as appropriate.

If it all worked, reclaim your physical hardware.


Note:  your disk controller and NIC must be supported by the cold clone boot CD.  I think you can add driver support somehow (it's been a while since I used it) but I've never done that.


----------



## frijsdijk (Sep 21, 2012)

I'd go for the wblock method. Install a 'skeleton' OS first (bootcode, filesystems, same FreeBSD RELEASE version and architecture), and then copy all the data on to it (via dump/restore as wblock mentioned), but I've done it multiple times using tar/nc, or even rsync.

The only things you will have to change on the VM are (probably) the network interface name (whatever it was, in VMware it will probably become em0/em1), and likely the disk (will become da0) - so don't forget to adjust the /etc/rc.conf for network settings, and the /etc/fstab for the device names).


----------



## throAU (Sep 21, 2012)

Yup, given the time I'd do it that was as well.  I mentioned cold clone for completeness 

However, cold clone has the additional benefit that you are not introducing any different software versions into the mix - the VM you end up with will be a pretty identical copy (software wise - other than NIC drivers) to what you had in production previously - so presumably compatibility testing, etc. will be simpler.


----------



## mamalos (Sep 23, 2012)

I usually do something close to what wblock suggests, but I think it's a bit easier:

I keep a tar(1) of all my files somewhere out of my PC (either remote server or USB disk. The latter is not the best solution for VMware, cos ESXi server isn't able to recognize external USB drives (at least ESXi-4), even when I tried doing it through its linux console...). Then, I boot a FreeBSD CD on the VM client, go to "Configure" and format the disk+install a boot loader. Then, I bsdlabel(8) it, I go to an emergency shell, mount(8) my newly created filesystem(s) and untar everything using tar(1) (over ssh(1)).

After a reboot, everything works like a charm (I've set more than 20 identical FreeBSD firewalls this way, and the whole process did not take more than 10 minutes for each instance. My installation was quite minimal, as you can imagine).


----------



## wblock@ (Sep 23, 2012)

throAU said:
			
		

> Yup, given the time I'd do it that was as well.  I mentioned cold clone for completeness
> 
> However, cold clone has the additional benefit that you are not introducing any different software versions into the mix - the VM you end up with will be a pretty identical copy (software wise - other than NIC drivers) to what you had in production previously - so presumably compatibility testing, etc. will be simpler.



Sorry, I don't understand.  If you restore over a minimal install, no new versions are introduced, you get what was in the backup.  If the minimal install was the same version, and it should be, everything is the same.


----------

