Yes it's perfectly possible, depending how well you know Linux you can either have a crack at imaging it into a VM with something like ghost, and changing the SCSI driver to the VMware one yourself, or use a comercial product like Platespin (quite pricey mind).
Take a look at these links.
I was under the impression the Converter could only P2V Windows machines?
Thanks for pointing that out, some how I missed to notice that it was a Linux host.
You absolutely corerct, it not going to work in this case
These are generic by necessity since every distro's sliiiiiiiightly different :-/
Whatever distribution you have installed, get the install media and perform a basic, stripped down installation on your vm guest.
On the new VM: Back up the /boot directory, /etc/fstab, /vmlinuz (this file may be in /boot/vmlinuz or /boot/vmlinuz-x.x.x) the lilo.conf (or grub.conf), and the /lib/modules/2.x.x directory.
Also /etc/modules.conf or the equivalent. If you have a floppy, "cat vmlinuz >/dev/fd0" just to make sure you can boot it if anything goes wrong here.
On the old "real server": Create a tarball of the entire filesystem in the root directory... i.e. "tar cvzpf filesystem.tgz boot/ bin/ etc/ home/ lib/ sbin/ usr/ root/ var/ opt/"
(list all your directories, separated by spaces, on that command. You don't need /proc and its up to you whether you need tmp or lost+found on the backup)
On the new VM: Move filesystem.tgz to "/". Extract it. Since this process will probably overwrite the files you backed up on the new VM in the first step (thereby rendering this VM unbootable if you shut down now):
If you'd like this new VM to boot afterwards do the following:
Restore those files you backed up from the new VM in the first step -- these files are not from the "real server" ! (/boot directory, the /lib/modules directory, the /etc/fstab, and the vmlinuz referenced in grub/lilo.conf. Also the modules.conf or conf.modules depending on distro.... pain in the neck trying to keep track of these inconsistencies, isn't it?
.... And of course the grub/lilo config file itself. )
\-- Then run "lilo" or "grub" depending on which your distro prefers, to build the MBR.
Do not make any changes on the old server (obviously) until you verify this has all worked correctly and your new system is alive after a reboot. You may need to reconfigure your network parameters (unless you're running a real distribution \*distro superiority dance* ... kidding)[/i], and/or kernel if you're doing anything extra special that needed to be built in.
Message was edited by:
Last time I did this, I created a VM of the appropriate size, booted it off a gentoo CD, and went the dd over ssh route. If your kernel is generic enough, you shouldn't have too much trouble with drivers...
I put the Linux drive in a machine with VMWare Workstation, created my VMDK, and then added a second hard drive with the "Use a physical drive" option. Then a "dd" command from the physical drive to my vmdk worked out nicely.
(That also works with IDE-based Windows systems. Boot the Windows system on its real hardware, change the IDE controller to "generic", create a new VM with a vmdk and then a second "physical" drive (that being the windows system).... do some dd magic with a linux boot disk, and reboot your new Windows server / let it detect the IDE chipset and virtual hardware -- Some people use Ghost or the like happily, but I don't have a copy of that laying around ...... interesting tip though bswopes, I never actually considered doing dd over an ssh pipe for that purpose -- windows or linux -- and I may try it in the future. Thanks!)
That works if your kernel supports buslogic/lsilogic natively. Some distributions load a kernel which doesn't (mine being one of those: you choose IDE or SCSI during install) so I got a VFS panic.
I got around that by using the scsi.s bootdisk and editing /etc/fstab to point to /dev/sda1 instead of /dev/hda1 ... then I rebooted using a "boot: scsi.s root=/dev/sda1" (everything came up natively) reconfigured/recompiled my kernel, and did a "make bzlilo". This is a quick, painless, and easy enough process. Unfortunately those slackware-specific instructions don't really help the Fedora / Gentoo / (insert distro here) people.
The process probably isnt too different for each, except that I don't know what disks/drivers are available for all those distros or who supports what hardware in the default kernels with each respective distro. While admittedly complicated, the aforementioned steps actually arent too different from how I migrate SCO boxes to VMs (which is about as fun as shaving with a cheese grater...)
dd over netcat is also pretty common, but netcat isn't in a lot of base installs, yet, so ssh does the trick. handy way to create an image of a system for forensic analysis, which is where I picked it up.
I decided to use Platespin PowerConvert, because I tried out all kind of methods using dd and other linux commands but no one could help me, now I'll try out PowerConvert, but I must pay for the license. Thanks!