Bart's Network Boot Disk & VMware
Today I started working on my first P2V-project, using VMware. The goal is to transform a Windows 2000 Server into a physical server running in a VMware Virtual Machine (P2V = Physical To Virtual). The server that we need to transform is needed in a branch office, while we - at Head Office - still need data and applications that still exist on the server. Also, I do not want to burden a specific server in this customer's LAN with the applications of the server that's leaving the office, so virtualizing it seems like a good option to me.
I came across a document on the VMware-website, Converting Image Files into Virtual Machine Disks, which mentions a very simple procedure how this should be done. It should go as follows:
Sounds fairly simple to me!
The document on the VMware-website discusses two ways of imaging the server, one of which is using Bart's Network Boot Disk. Bart's disk works really really fantastic!! I just downloaded the Auto-create-version after which creating the boot disk was just a matter of typing one command on a command prompt and the disk was ready!
After booting from the disk and starting GHOST.EXE to dump my image from the source server to the destination machine, I ran into two things:
1. Destination image files cannot be larger than 2GB, and
2. We experienced quite poor performance creating the image
The first problem is a very logical one: as Bart's Network Boot Disk is a Windows98-disk, there is the FAT-limitation of 2GB. No problem for Ghost, just split the image in separate file and you're done. The second problem is discussed in the FAQ on Bart's Network Boot Disk webpage, and has to do with using TCP/IP and copying large files from a DOS-based machine to a Windows 2000-based machine. Bart offers a link to a Microsoft-page discussing this issue, and this issue can be resolved by altering the TCPWindowSize on the destination server. I decided not go changing such basic parameters and just used IPX/SPX to get the image created. I was quite amazed to see the image getting created twice as fast as when using TCP/IP. So, two problems solved.
So, after booting the source server with Bart's disk, I was reading to start the imaging. I was surprised to see the image procedure crash at some 7.5Gb (where my source server has about 14Gb space in use). I restarted Ghost to start the image again, and now it crashed at 4.something Gb. What was happening? Maybe there was something wrong between Ghost and the RAID controller? After checking Symantec's website, I learned that GHOST and RAID are not compatible. Symantec does explicitly NOT support using Ghost with RAID-machines. However, they do offer some options. One of them was trying to run the image again with DOS ASPI drivers loaded. I tried that, and succeeded. So after loading ASPI2DOS, ASPI4DOS, ASPI8DOS and ASPI8U2, Ghost would image my interne source server disk to the destination server.
One day later...
OK, after creating an image from the source server I was ready to restore it to the VMware host machine.
I had created a virtual boot floppy file (using WinImage) and configured a new VM to boot from this floppy file. All went went, so after booting I ended up with an empty VM, a DOS-prompt and a connection to the server where the image was put upon (I will call it the "image server" from now on). Nothing would stop me from logging on to the image server and start GHOST to restore the image to the VM's virtual local disk. However, I have come across some problems and finally found a workaround, of which I am not very proud...
I tried the following:
* Boot VM to DOS, access the image server over TCP/IP, start Ghost and restore the image --> was quite slow, just 90Mb/min.
* Boot VM to DOS, access the image server over IPX/SPX (recalling the above mentioned performance issue when connecting to a Windows 2000 Server from DOS), start Ghost and restore the image --> even slower, only 60Mb/min
I also tried the following: as my VMware-server and the image server are physically the same machine, I tried copying the image files from the image server to another server I had around, and tried to restore the images from there. Same problem, still too slow.
Next try was to try to restore the images from the local disk of the image server (as the VMware-server and the image server were the same server). But, in that scenario, I had to find a way to access the server's local disks from within the virtual machine. I tried NTFSDOS from SysInternals, and was able to "see" and access the server local disks from within the VM. There were two options now:
* just boot the VM, start Ghost and restore the image; did not work, Ghost would complain the image file was not a valid Ghost image file (which it was!)
* create a second local disk in the VM, boot the VM, access the local disk from within the VM, copy image files to the VM and then try to use Ghost; this also did not work, because the files could be copied reliably.
There obviously was a problem with NTFSDOS, which prevented the VM from reading and/or copying file from the local disk.
So.... I was quite running out of options. A colleague of mine came up with the idea of booting the VM with a WinPE-CD (because NTFS-support is fine in XP) to see if we would be able to access the local disks and copy the files from there (to the second local disk in the VM). This did work well and as we speak the server is restoring the image to the first local VM disk.
To be continued...
I came across a document on the VMware-website, Converting Image Files into Virtual Machine Disks, which mentions a very simple procedure how this should be done. It should go as follows:
- Image the existing server
- Install VMware on the host server and create a new, empty virtual machine
- Restore the image into the newly created virtual machine
- Done!
Sounds fairly simple to me!
The document on the VMware-website discusses two ways of imaging the server, one of which is using Bart's Network Boot Disk. Bart's disk works really really fantastic!! I just downloaded the Auto-create-version after which creating the boot disk was just a matter of typing one command on a command prompt and the disk was ready!
After booting from the disk and starting GHOST.EXE to dump my image from the source server to the destination machine, I ran into two things:
1. Destination image files cannot be larger than 2GB, and
2. We experienced quite poor performance creating the image
The first problem is a very logical one: as Bart's Network Boot Disk is a Windows98-disk, there is the FAT-limitation of 2GB. No problem for Ghost, just split the image in separate file and you're done. The second problem is discussed in the FAQ on Bart's Network Boot Disk webpage, and has to do with using TCP/IP and copying large files from a DOS-based machine to a Windows 2000-based machine. Bart offers a link to a Microsoft-page discussing this issue, and this issue can be resolved by altering the TCPWindowSize on the destination server. I decided not go changing such basic parameters and just used IPX/SPX to get the image created. I was quite amazed to see the image getting created twice as fast as when using TCP/IP. So, two problems solved.
So, after booting the source server with Bart's disk, I was reading to start the imaging. I was surprised to see the image procedure crash at some 7.5Gb (where my source server has about 14Gb space in use). I restarted Ghost to start the image again, and now it crashed at 4.something Gb. What was happening? Maybe there was something wrong between Ghost and the RAID controller? After checking Symantec's website, I learned that GHOST and RAID are not compatible. Symantec does explicitly NOT support using Ghost with RAID-machines. However, they do offer some options. One of them was trying to run the image again with DOS ASPI drivers loaded. I tried that, and succeeded. So after loading ASPI2DOS, ASPI4DOS, ASPI8DOS and ASPI8U2, Ghost would image my interne source server disk to the destination server.
One day later...
OK, after creating an image from the source server I was ready to restore it to the VMware host machine.
I had created a virtual boot floppy file (using WinImage) and configured a new VM to boot from this floppy file. All went went, so after booting I ended up with an empty VM, a DOS-prompt and a connection to the server where the image was put upon (I will call it the "image server" from now on). Nothing would stop me from logging on to the image server and start GHOST to restore the image to the VM's virtual local disk. However, I have come across some problems and finally found a workaround, of which I am not very proud...
I tried the following:
* Boot VM to DOS, access the image server over TCP/IP, start Ghost and restore the image --> was quite slow, just 90Mb/min.
* Boot VM to DOS, access the image server over IPX/SPX (recalling the above mentioned performance issue when connecting to a Windows 2000 Server from DOS), start Ghost and restore the image --> even slower, only 60Mb/min
I also tried the following: as my VMware-server and the image server are physically the same machine, I tried copying the image files from the image server to another server I had around, and tried to restore the images from there. Same problem, still too slow.
Next try was to try to restore the images from the local disk of the image server (as the VMware-server and the image server were the same server). But, in that scenario, I had to find a way to access the server's local disks from within the virtual machine. I tried NTFSDOS from SysInternals, and was able to "see" and access the server local disks from within the VM. There were two options now:
* just boot the VM, start Ghost and restore the image; did not work, Ghost would complain the image file was not a valid Ghost image file (which it was!)
* create a second local disk in the VM, boot the VM, access the local disk from within the VM, copy image files to the VM and then try to use Ghost; this also did not work, because the files could be copied reliably.
There obviously was a problem with NTFSDOS, which prevented the VM from reading and/or copying file from the local disk.
So.... I was quite running out of options. A colleague of mine came up with the idea of booting the VM with a WinPE-CD (because NTFS-support is fine in XP) to see if we would be able to access the local disks and copy the files from there (to the second local disk in the VM). This did work well and as we speak the server is restoring the image to the first local VM disk.
To be continued...
Reacties