Novell Cool Solutions

NetWare Physical to Virtual (P2V) Conversion Process With Free Tools


October 13, 2009 3:29 pm





How to perform a NetWare Physical to Virtual conversion using free tools.


Recently I had the requirement to duplicate a production server in a test environment. The source server was NetWare 6.5 running on HP Proliant DL380 G4 hardware. As all of our servers use a pair of mirrored disks for the system (dos partition and SYS pool / volume), the most obvious solution was to remove one of the system disks and put it into some spare (and reasonably similar) hardware. This would certainly work, but would mean that I would be fairly limited in maintaining a roll back position for when my testing went wrong and I wanted to start over.

Virtualisation is a popular technology these days (rightly so) and is a perfect fit for a test environment where you wish to be able to quickly recover to a known point and potentially spawn additional copies of your test environment. I decided to investigate my options for performing a NetWare Physical to Virtual (P2V) conversion.

The only current commercial offering I could find was Portlock Storage Manager ( which looks like a very powerful tool, but was a little too expensive for what I needed (but could be a good option for doing production conversions).

I decided to see if I could make something work with free tools, and after a little experimentation and a lot of googling, found a bunch of tools and a process that has worked for me and which I will describe in this article.

Tools Used:

  • Windows XP Workstation with the NetWare Client and enough storage to hold an image of our source server (an external USB drive is handy for this)
  • Clonezilla 1.2.2-26 Live CD (
    • Linux based GPL imaging solution
  • VMware ESXi 4 (
    • Hypervisor
  • DR-Dos 7.0.3 (
    • A free DOS we can use to boot our NetWare Server
    • Hint – you if own Nero Burning ROM you can create a DR-DOS boot CD by burning a blank “bootable” CD-ROM (MagicISO can turn this into an ISO file for you)
    • You can download this one I generated (and which includes XCOPY) – DR-DOS.iso
  • MagicISO (
    • Shareware ISO manipulation software, the trial version is capable of managing ISO’s up to 300MB which is sufficient for the use we put it to in this process

The skills needed to complete this exercise are:

  • Intermediate with VMWare ESXi
  • Intermediate with NetWare 6.5
  • Intermediate General IT skills

Summary of the process:

The concept of what we want to do is relatively straight forward. We simply want to take an image of our existing server which is hosted on physical hardware and restore this image into a virtual machine hosted on our ESXi hypervisor.

Pros of approach:

  • Cheap (the only cost is your time, which to be fair might not be cheap)
  • Source server remains unmodified
  • Seems to work

Cons of approach:

  • Quite a bit of down time required
    • Source server imaging occurs offline
    • If you are replacing the source server, then the time is doubled due to the restore time

Step 1: Preparation

  • Download the following software and have it available on your workstation
    • Clonezilla 1.2.2-26 Live CD
    • DR-DOS 7.0.3 Boot CD / ISO image

      Note – if you use the Nero generated ISO, it does not include XCOPY (which will save you a lot of time later on), so download XCOPY.EXE from the DR-DOS website and include it in your ISO (with MagicISO – you’ll see how to do this later in this article)
    • Magic ISO (install on your workstation)
  • Ensure you have a VMware ESXi 4 hypervisor configured and running that has the capacity required to host the new virtual server. Setting up ESXi is beyond this scope of this article but more information can be found on the VMWare website.
  • Ensure you can make an NCP connection to the source server you want to convert and have the appropriate server privileges (essentially you should be supervisor of the server).
  • Ensure you have enough disk capacity on your workstation to hold an image of the source server’s entire system disk. An external USB drive might be useful here, especially if your production and test networks are separated (this is a very good idea BTW).
  • Setup a Windows Share on your client PC
    • Ensure this is where you have allocated the disk space for the source server image as this is the location we will send our image to.
  • Create a new Virtual Machine which we will move the image of our physical server to
    • Amount of RAM should be the same as the source physical server
    • SCSI controller should be of type LSI Logic Parallel
    • Local Hard Disk should be SCSI and made slightly larger than the source physical servers disk (in this example the source servers disk is 36GB so I have created a 40GB virtual disk)
    • The virtual network adaptor should be created as a “Flexible” adaptor
  • Connect to the console of your source server and load the DOSFAT module (see Figure 1). With the DOSFAT module loaded, the source servers DOS volume (C drive) will be available as an NCP volume. In this case it is presented as DOSFAT_C

    Click to view.

    Figure 1 (Load DOSFAT)

  • Now connect to this volume from your windows client (see Figure 2) and copy its entire contents

    Click to view.

    Figure 2 (Servers C Drive as a NetWare Volume)

    We need to copy the contents of the servers C drive is so that later in the process we can restore the virtual server’s C drive to the same state. My experience with imaging HP servers has been that the DOS partition will come across, but will not be bootable and this does not seem to be easily fixable. It may be to do with some issue around the differences in geometry between the physical and virtual disks but to be honest I don’t completely understand the issues and reformatting the DOS partition resolves the issue quickly and easily and so that has been my approach.

Step 2: Image the source server

  • Shutdown the source server
  • Load the Clonezilla 1.2.2-26 Live CD into the CD-ROM drive of the source server and boot from it (note that in my case I used the HP Integrated Lights Out Functionality to remotely mount the ISO image on the server, and remote control the physical console see Figure 3 and 4 )

    Click to view.

    Figure 3 (HP iLO is used to mount the Clonezilla ISO on the source server)

    Click to view.

    Figure 4 (HP iLO is used to view the servers physical console as Clonezilla Boots)

  • At the Clonezilla splash screen, select the appropriate screen resolution for your server (in this case 800×600 works well)
  • Next you will be prompted to select the language you prefer to work in (this guide assumes English), so choose English
  • Next you will be prompted to select the KeyMap you prefer to use, I choose “Don’t Touch KeyMap”
  • The LiveCD will now ask if you wish to start Clonezilla or drop to the command line, you should choose to start Clonezilla (see Figure 5)

    Click to view.

    Figure 5 (Start Clonezilla)

  • Clonezilla now needs to know what mode you wish to operate in, device to image or device to device. We want to use device-image. This mode can be used to create a file based image of a physical storage device in our source server, so choose device-image (see Figure 6)

    Click to view.

    Figure 6 (choose device-image mode)

  • Clonezilla will now ask what it should use as the device for storing / retrieving image files. In this example we want to push the image across the network to our Windows XP client. The simplest way to do this is via the “samba_share” option which will allow us to connect to the share we set up on our Windows client earlier (see Figure 7)

    Click to view.

    Figure 7 (choose samba_server)

  • As we have chosen a network location for our image file, we are now prompted for how we would like to configure the IP address to be used by Clonezilla. For this example we will use a static address (see Figure 8), and I would recommend that you don’t use the same IP address that the source NetWare server has been allocated

    Click to view.

    Figure 8 (choose how to assign a network address – we will use static)

  • You will be prompted for the following information
    • IP address for eth0 (the local IP address to assign to Clonezilla)
    • Enter a valid IP address on your network and click OK (or hit enter)
    • Network Mask
    • Enter the network mask for your network and click OK (or hit enter)
    • Default Gateway
    • Enter the default gateway for your network – this is especially important if your client machine is located on a different subnet to your source server. If you do not have or need a gateway, select cancel on this dialogue (rather than OK)
    • Nameservers
    • Enter the IP address of the nameserver(s) on your network. This is not required if you are connecting via IP addresses (which is the simplest way to do it). Again, clicking on cancel will bypass this parameter
    • Mount Samba Server
    • Enter the IP address of your Windows XP client machine (the location where you created the Windows Share earlier) and click OK (See Figure 9.)

    Click to view.

    Figure 9 (Enter the address of the machine that will receive the image file)

  • Samba Server Domain
    • If your windows XP client belongs to an Active Directory or NT domain, this is where you specify its name. If your client is simply in a workgroup you can leave this dialogue empty and click cancel (my client was in a workgroup so I have not tested how domain membership affects connectivity)
  • Samba Server User Name
    • Enter the username of a user on your Windows client that has permissions to connect to the share you configured earlier (see Figure 10)

    Click to view.

    Figure 10 (Enter the username to connect to your Windows share as)

  • Samba Share Name (Directory Name)
    • Enter the name of the share that you created on your Windows client (see Figure 11) – i.e the name of the share you will connect to for saving the image

    Click to view.

    Figure 11 (Enter the name of the share you created on your Windows client)

  • Finally you will be prompted for the password (of the user account specified above) to be used to connect to the share on your Windows client. If the connection is successful you will see a filesystem summary displayed that shows your Windows share mapped to /home/partimag on the Clonezilla machine (see Figure 12). Hit enter to continue.

    Click to view.

    Figure 12 (Clonezilla successfully mounted our Windows share)

  • Now you will be asked if you would like to run the “Beginner” or “Expert” wizard for imaging (Figure 13). After some experimentation, I came to the conclusion that Beginner mode does fine for imaging up a source NetWare server. In beginner mode Clonezilla will step through its available imaging tools looking for the most appropriate one to image our source server. As there are no specific tools in Clonezilla that know about NSS partitions, it will eventually drop down to using “DD” to create the image of the NSS partition (and partimage for the DOS partition). By default, the beginner wizard will also compress the image (using gzip) and split the image file into 2GB chunks. The smart thing about Clonezilla is that it will also take a copy of the partition table which it will use to reconstruct our disk when we restore it.

    Click to view.

    Figure 13 (We choose the Beginner wizard)

  • After selecting the “Beginner” wizard, Clonezilla will ask us what type of imaging operation we would like to perform. In this case we want to perform a “savedisk” operation which images a disk in its entirety (see Figure 14).

    Click to view.

    Figure 14 (We choose the savedisk imaging option)

  • Next we are required to enter the name of the image we are taking (see Figure 15) – in this case I have called it Replica-img. Clonezilla will create a directory in the root of the Windows Share named “Replica-img” into which all of the imaging data for this server will be saved.

    Click to view.

    Figure 15 (Name our image)

  • Next we need to choose the source disk we wish to image (see Figure 16). In this case there is only one disk in our system, so the choice is easy. It is entirely possible however that you might wish to image a server with multiple disks. In this case, if the other disks simply contain data, it may simply be easier to restore this data onto the Virtual server once it has been provisioned. One exception to this is where NSS partitions span disks. If your SYS volume spans disks, you will need to image all disks and bring them all across to the virtual environment as if you don’t, you wont have all of the data that makes up that volume. This process has only been tested with single disk (or LUN in the case of a “disk” being made up of a mirrored pair of disks) where the SYS pool/volume does not span outside of this set.

    Click to view.

    Figure 16 (select the source disk to image)

  • Clonezilla will now provide a summary of the command it will use to image the device and ask for confirmation before beginning. Assuming that the location you wish to save your image (the windows share that clonezilla has connected to) is writable, the imaging process will begin and provide a progress indicator (see Figure 17)

    Click to view.

    Figure 17 (Imaging process commences)

  • Once the imaging process is complete (see you can remove the Clonezilla CD-ROM / disconnect the ISO and reboot the server. In this example we are taking the image to deploy into a test environment so we will bring the source server back up. If the target server was intended to replace the source server, then we would power down the source server and physically disconnect it from the network to avoid any potential server conflicts.

Step 3: Restore the image to the virtual server

Now that we have an image of our source server we need to reverse the process to extract the image to our virtual server. The virtual server requires network access to a Windows share that contains the image we took in step 2. Because in this example we are migrating the source server to a test environment, the source server will remain online and so the test environment must be isolated from production (or the network the source server operates on) to avoid server conflicts.


In this example I take the external USB drive that was connected to my Windows XP workstation and connect it to a Windows XP workstation on my test network. The networks that my source (physical) and destination (virtual) servers are connected to are PHYSICALLY ISOLATED and there is no chance of cross contamination. Please ensure this is the case for you if you are leaving the source server operational.

Clonezilla is used to restore the source image into the virtual machine. The process for starting Clonezilla and connecting to our Windows XP client (windows share) is identical to that described above in Step 2 “Image the Source Server” and so will not be repeated here. This step will describe the differences between restoring and creating an image and any specific’s around the virtual environment.

  • Connect the virtual CDROM drive of your destination virtual server to the Clonezilla 1.2.2-26 Live CD ISO image (see Figure 18)

    Click to view.

    Figure 18 (Connect the Clonezilla ISO to your virtual server)

  • Power on your virtual server, boot with the Clonezilla Live ISO and proceed with Clonezilla configuration up until the Clonezilla “Imaging Operation” selection dialogue (see Figure 19)

    Click to view.

    Figure 19 (Imaging Operation Selection Screen)

  • On the imaging operation screen (see Figure 19), select the “restoredisk” option. This option will restore our previously saved image back to a physical device (or in this case a physical drive virtualized by the VMware hypervisor)
  • A list of available images will now be displayed from which you can choose the image to restore (see Figure 20). In this example we will choose “Replica-img” which is the image we created in Step 2 above.

    Click to view.

    Figure 20 (select the image to restore)

  • Now we will be prompted to select the local disk device onto which to restore the image (see Figure 21). As this virtual server only has one disk device, we only have one option.

    Click to view.

    Figure 21 (select target disk device to restore the image to)

  • Clonezilla will now provide a summary of the command it will use to restore the image to the device, along with a summary of the layout to be restore and ask for confirmation before beginning (see Figure 22)

    Clonezilla will now restore the partition table and the data from the image (see Figures 23 and 24)

    Click to view.

    Figure 23 (Clonezilla rewrites the partition table based on the image)

    Click to view.

    Figure 24 (Clonezilla restores the data from the image)

  • When the imaging process completes, remove the virtual CD and reboot the virtual server. If your virtual server is anything like mine, it won’t boot (see Figure 25). If so, proceed to Step 4.

    Click to view.

    Figure 25 (Our virtual server with the image restored wont boot)

Step 4: Fix the DOS partition of the restored image

Now that we have restored the image into our virtual server it requires some work to become useable. There are two things we need to do.

  1. Fix the DOS boot partition (this is where DR-DOS comes in)
  2. Modify the NetWare installation to use the new VM hardware (disk and network controllers)

You may wish to re-use the DOS that your source server originally had installed, if so, then you will need to extrapolate the process from what is described here with DR-DOS. I have tested this with MS-DOS and it works fine. DR-DOS is simply used here in this example as it is, well, free.

The approach for fixing the DOS partition is:

  • Create a DOS boot ISO/CD specific for this server (with all the source servers C drive files)
  • Boot the virtual server with the DOS boot ISO/CD
  • Format the virtual servers DOS partition using the tools on the boot CD
  • Copy across DOS to the virtual servers DOS partition
  • Copy the NWSERVER directory of the source server from the ISO to the newly formatted DOS partition

The approach for modifying the NetWare installation is:

  • Remark out any hardware specific drivers (specific to the old server hardware) loaded in the servers STARTUP.NCF
  • Add a line to load a suitable VMware disk device driver in the STARTUP.NCF
  • Start the server with no autoexec.ncf execution
  • Use HDETECT to load a suitable VMWare NIC driver

Fix the DOS boot partition

  • On the Windows XP workstation onto which you installed MagicISO, make a copy of the DR-DOS ISO image. In this example, I have called the copy DR-DOS-Replica.iso. Use MagicISO to open this new DR-DOS ISO image (see Figure 26).

    Click to view.

    Figure 26 (MagicISO with the DR-DOS-Replica.iso image open)

  • Now from within MagicISO, copy across the source servers C drive that we backed up to our Workstation in Step 1 (see Figure 27). In this example the source servers C drive is backed up to a directory called “Replica” that is located in another directory called “Source Server C Drive”. Using the MagicISO GUI we can drag the “Replica” directory from the bottom explorer window into the top DR-DOS-Replica.ISO image window.

    Click to view.

    Figure 27 (The source servers C drive backup directory “Replica” is added to the ISO image)

  • Now use the “Save” option from the file menu to save this ISO image and then close it.
  • The updated ISO image (in this example DR-DOS-Replica.ISO) should now be uploaded to a data store on the ESXi hypervisor so that it can be used by Virtual Servers. Use the vSphere client to upload this ISO to your ESXi server (see Figure 28).

    Click to view.

    Figure 28 (The new ISO file is uploaded to the ESXi server)

  • Now we need to insert (or mount) this ISO on the target virtual server’s virtual CD ROM drive (see Figure 29) ensuring that the CD ROM device is connected.

    Click to view.

    Figure 29 (The FreeDOS-Replica.iso is mounted on the virtual server)

  • Now boot the virtual server from the DR-DOS-Replica.iso virtual CD. You should find yourself at a DR-DOS command line prompt (see Figure 30)

    Click to view.

    Figure 30 (DR-DOS boot splash screen)

  • The DOS partition on the virtual server now needs to be reformatted and the files from the source servers C drive (that we backed up earlier), copied onto the newly formatted DOS partition. Use the DOS command “format c: /s /x” to format the DOS partition and transfer the base DOS boot code (see Figure 31)

    Click to view.

    Figure 31 (The virtual servers C drive is formatted)

  • Now transfer the DR-DOS support files from the A drive to the newly formatted C drive by issuing the command “xcopy a:\drdos c:\drdos /s/e/v”. Note – You will need to ensure you have xcopy on your boot ISO.
  • Now copy the NWSERVER directory (this is from the original source server and is what you copied into the DR-DOS ISO image) from the virtual CDROM drive (this will be drive letter D if you are using the boot image supplied with this guide) to the C drive of your virtual server. In this example the command to use is “xcopy d:\replica\nwserver c:\nwserver /s/e/v”
  • You can now eject the DR-DOS ISO image from the virtual CD-ROM drive of the virtual server and reboot. If everything has worked as expected the virtual server will boot from the C drive and drop you into a DR-DOS command prompt (see Figure 32)

    Click to view.

    Figure 32 (The virtual server has booted from the C drive to DR-DOS)

Step 5: Fix the NetWare Server Installation

The final step in the conversion process is to ensure that the appropriate device drivers load for NetWare to be able to access the VMWare virtual disk and VMWare virtual NIC. In addition, we will comment out any hardware specific drivers required for the server’s original hardware platform.

  • If you are continuing from the end of Step 4 you should be at the C:\ prompt of your virtual server. Navigate to the NWSERVER directory and issue the command “edit startup.ncf” to edit the NetWare server’s startup.ncf file. Note, if you receive a message stating that the file is “read-only”, issue the following at the command prompt to make it writable “attrib startup.ncf -r”. In addition, ensure that if the “startup.bak” file exists, that it too is writable.
  • Comment out any hardware specific device drivers for the old server, in this example the following lines are commented out
  • Add the following lines to load device support for the VMWare disk devices
    NOTE: If the slot values you specify don’t work, when the server loads it will stop and prompt you to enter a valid (useable) slot number – if this occurs, ensure you update the startup.ncf with the correct value.

    See figure 33 for the final startup.ncf as used in this example

    Click to view.

    Figure 33 (startup.ncf file for the virtual server)

  • Now load the NetWare server with the command “server –na” from the NWSERVER directory. This command will start the NetWare server instance without executing the autoexec.ncf file.
  • Once the NetWare server reaches the NetWare console prompt, execute the command “hdetect” (see Figure 34) to launch the NetWare hardware detection utility (see Figure 35)

    Click to view.

    Figure 34 (HDETECT is launched from the NetWare server console)

    Click to view.

    Figure 35 (HDETECT initial screen – platform device drivers)

  • Select “Continue” on the initial screen to move to the Storage and Network device drivers screen (see Figure 36). This screen should indicate that no NIC driver is loaded.

    Click to view.

    Figure 36 (HDETECT shows that no NIC driver is loaded)

  • Choose “Modify” from the options menu and then navigate to the “Network Boards” field and press enter.
  • On the Network Board Driver screen (see Figure 37), navigate to the “Modify” option and press enter.

    Click to view.

    Figure 37 (HDETECT Network Board Driver Screen shows no drivers loaded)

  • Now hit the “INS” key to insert a new driver and navigate to and select (by hitting enter) the “CNEAMD.LAN: Novell Ethernet PCNetPCI, PCnetPCI_II, PCnet-Fast” driver (see Figure 38)

    Click to view.

    Figure 38 (Navigate to and select the NIC driver)

  • The NIC driver summary screen will now be shown, and should contain the correct SLOT settings (See figure 39)

    Click to view.

    Figure 39 (Selected NIC driver summary screen)

  • Now choose the option to return to the driver list
  • Now choose the option to return to the driver summary
  • At the driver summary screen (see Figure 40), you should now see that a NIC driver is selected. Choose the option to continue.

    Click to view.

    Figure 40 (Driver summary now shows a NIC driver selected)

  • The next screen (see Figure 41) allows you to configure protocols for your Network Board. Select “Configure Protocols” from the options menu, highlight the Driver in the top window and hit enter.

    Click to view.

    Figure 41 (The Protocol configuration screen for the NIC boards)

  • On the board configuration screen (see Figure 42), choose the “Configure IP Protocols” option, then highlight the Ehternet_II frame type and hit enter.

    Click to view.

    Figure 42 (NIC Board Configuration Screen)

  • At this point HDETECT might seem to hang if you don’t have a DHCP server on the same network as your virtual server. This is because the NetWare server attempts to discover some IP configuration details via DHCP. After around 30 seconds (if no DHCP server responds), the protocol properties screen will appear (see Figure 43).

    Click to view.

    Figure 43 (TCPIP protocol properties screen)

  • Select the “Modify protocol properties” option and complete the TCPIP information as appropriate for your environment – IP address, Subnet Mask and default gateway (if you have one). Once entered, select “Continue” to return to the Network Board protocol configuration summary screen.
  • Now select the “Return to driver summary” option
  • Now select the “Continue” option and the driver should bind to the card

    Note: You may be prompted to remove any “questionable” entries from the startup.ncf and autoexec.ncf. Questionable entries are drivers that HDETECT believes are not useable on this hardware platform
  • HDETECT should now exit and the NIC should be loaded and bound – issue the command “config” from the NetWare server console to confirm (see Figure 44)

    Click to view.

    Figure 44 (The NIC is loaded and TCPIP is bound)

  • Your virtual NetWare server should now be ready for use. To confirm, DOWN the server and restart.
  • The final task you might like to complete is the creation of an “autoexec.bat” file on the C drive to autostart NetWare when the virtual server boots.
1 vote, average: 5.00 out of 51 vote, average: 5.00 out of 51 vote, average: 5.00 out of 51 vote, average: 5.00 out of 51 vote, average: 5.00 out of 5 (1 votes, average: 5.00 out of 5)
You need to be a registered member to rate this post.

Categories: Uncategorized


Disclaimer: This content is not supported by Novell. It was contributed by a community member and is published "as is." It seems to have worked for at least one person, and might work for you. But please be sure to test it thoroughly before using it in a production environment.


  1. By:clausbc

    great detailed article – thanks. I would, however, be even more interesting with a similar P2V description with XEN Virtualization is the target.

  2. By:9555269

    The reason there aren’t any P2V utilities for NetWare is because there is already a proven, well documented, robust process for doing a “hardware migration” of a server. Just because the target is a VM, the process is no different. We’ve been using this tool (and it’s forebears) for over a decade and it is unparalleled.

    PortLock isn’t bad, and your CloneZilla process is functional. WIth SCMT, the source server never goes offline. Even if you’re doing a production move (to new hardware or to VM) the service interruption can be reduced to minutes on most every server. If you are bringing up a clone in a sandbox, you NEVER interrupt service.

    1. The source server never has to go offline
    2. The target server can be preconfigured with all the right drivers
    3. The target is platform independant.

    You’ve reinvented the wheel. This process is “spinners” when a simple rims suffice… Admittedly, there are issues with the SCMT on the Linux side, but for a NetWare to NetWare “Server Identity” migration, is the best tool, no matter how chrome-plated the alternatives might be.

    • By:gavo

      I didnt use SCMT because it didnt meet my requirement of taking a _copy_ of my server for use in my test environment.

      I agree that if I had wanted to migrate the identity of a server onto new server hardware that I had prepared as a “pre-migration server”, or consolidate services onto a new server – SCMT would be the way to go.


    • By:konecnya

      I have used SCMT a few times where it was really useful, but it is not a clone of the box, it is very distinctly a new running environment that just happens to have the same name and address as the old server. I usually spent more time getting those systems working right post SCMT migrating than any of the total cloning process time described here.
      In my recent case, the server was the CA, the IDM connector, NSure Audit server, and a Sybase server. I really don’t see how SCMT would have helped for any of those applications.

  3. By:clausbc

    correct me if I am wrong, but SCMT will only support basic File og Print services, no applications are migrated. That is the primary reason for using Portlock or others.

  4. By:msong

    anybody tried this?
    it seems lost all NSS volumes other than SYS.

  5. By:msbrentlinger

    Thanks for the great guide gavo this worked very well for me.

    In running thru this guide I used some alternative ways to
    1) Get an image of my source server and restore it to my target VM
    2) Get my c:\nwserver dos files saved off without the need to load DOSFAT

    I thought posting it may be of help to someone… so here goes.

    For my alternative to Get an image of my source server and restore it to my target VM
    I booted my server and a virtual machine I created both off backtrack live cds

    On both the original server and my new target vm I started networking in backtrack live via
    /etc/init.d/networking start
    I then found my source disk on my source server and my target disk on my target vm server by grepping thru dmesg

    For example. My source is a HP DL380 G2 with a compaq raid adapter… so
    did a
    dmesg | grep -i ccis
    to see /dev/cciss/c0d0
    did a
    fdisk -l /dev/cciss/c0d0
    to see 3 partitions… dos, sys and vol1 within nss as c0d0p1 c0d0p2 and c0d0p3

    Similarly on my vm target I did
    dmesg | grep -i sd
    to see /dev/sda as my target drive

    On my source server I took an image of the drive and streamed it to my target server over the network via netcat.

    Source server IP address of a.a.a.a
    Target server IP address of b.b.b.b

    On my target server I started a listener waiting to receive the image and load it on the vmware drive
    nc -l -p 5555 | dd of=/dev/sda

    On my source server I then initiated the transfer of the drive image
    dd if=/dev/cciss/c0d0 | nc b.b.b.b 5555

    Some notes / tips you should be aware of:
    A) The target drive needs to be at least as big or bigger than the source drive.
    B) You should do this over a fast network line to speed the transfer
    C) If you want to see a status of your dd transfer you can always do a kill -SIGUSR1 on the dd pid and youll get a progress report of how far dd is in finishing the transfer.
    On either system hit clt+alt+f2 to flip to a different console and type “ps -aux | grep dd” Thatll get you a process ID of dd that you can then run “kill -SIGUSR1 xxxx” where xxxx is the pid of dd. Then press ctrl+alt+f1 to go back to the first console and see the dd status

    For my alternative to Get c:\nwserver dos files saved off w/o the need to load DOSFAT

    You could also use DD and netcat to make an image of your source server and store it as a file somewhere…. You can then open that image and pull out your DOS files from the image.

    In this setup I still booted my source server off a backtrack live cd and started networking and found my source drive I want an image of…

    Source server IP address of a.a.a.a
    My file server thats going to receive the drive image and save it as a file has an IP of b.b.b.b

    On a my file server linux box thats going to receive the source image I started netcat in a listening state waiting to receive the source drive but this time to save it as a image file…
    nc -l -p 5555 | dd of=p2v-test-ready-for-vmware.dd
    This will receive the file from my source and save it as p2v-test-ready-for-vmware.dd

    On my source server I again do a
    dd if=/dev/cciss/c0d0 | nc b.b.b.b 5555

    And let it finish… when its done youll have a file p2v-test-ready-for-vmware.dd which is an exact clone of your sources hard disk which you can mount and extract files from using parted and mount

    For example, I mounted my source image from on my file server that just received the image from my source.

    root@mikbrent-vm:/mnt/sdb1# parted p2v-test-ready-for-vmware.dd
    GNU Parted 2.2
    Using /mnt/sdb1/p2v-test-ready-for-vmware.dd
    Welcome to GNU Parted! Type ‘help’ to view a list of commands.
    (parted) unit
    Unit? [compact]?
    (parted) unit
    Unit? [compact]? B
    (parted) print
    Model: (file)
    Disk /mnt/sdb1/p2v-test-ready-for-vmware.dd: 109244252160B
    Sector size (logical/physical): 512B/512B
    Partition Table: msdos

    Number Start End Size Type File system Flags
    1 16384B 108625919B 108609536B primary fat16 boot
    2 108625920B 5356093439B 5247467520B primary
    3 5356093440B 15842672639B 10486579200B primary

    (parted) q
    root@mikbrent-vm:/mnt/sdb1# mkdir /tmp/disk_image
    root@mikbrent-vm:/mnt/sdb1# mount -o loop,ro,offset=16384 p2v-test-ready-for-vmware.dd /tmp/disk_image
    root@mikbrent-vm:/mnt/sdb1# ls /tmp/d/isk_image

  6. By:bradvuong

    Great article/guide. However, when I try to restore to my virtual server, I get the following error:

    Error: can’t have a partition outside the disk!

    And I am not able to restore.

    I created a partition on my virtual server that is larger than the partition that I imaged but I still get this error.

  7. By:armin_w

    Wonderful article, I’m not sure if I could work it out without it – as I stopped really using Netware after 3.12 😉

    I had big problems with – current – Cloezilla versions. I was able to create a disk image of the original server and saved it to a Windows share on my local workstation, but during restore, Clonezilla on the VM didn’t seem to see the previously saved image, so I couldn’t restore.

    Being annoyed about that and being unable to find a solution, I next tried a sector-by-sector copy to a locally attached USB drive with Acronis TrueImage. Image backup went fine and even the restore finished without telling me of a problem.
    So the Netware server booted up fine in the VM after restore but didn’t see/mount any of the NSS volumes, not even the SYS volume.

    Being even more annoyed about not getting it to work after quite a couple of hours (copying ~150G always takes a while…) I thought I give the dd/netcat method a try. AND – it worked :-)

    What I did in short words:
    – No need to prepare the original server!
    – Boot the original server with a Linux Live CD (in my case the current Knoppix CD)
    – Run “fdisk -l” on the original server to see what drives are around and what the exact size is (in my case /dev/cciss/c0d0, /dev/cciss/c0d1 and /dev/cciss/c0d2)
    – Create a VM with the same number of drives (3 in my case), each drive at least the same size than on the original server
    – Boot the VM with a Live Linux (I used the same ISO image like on the old server)
    – Open a console on both, the original and the new VM server
    – Do the same fdisk -l thing on the VM to make sure the drives (/dev/sda…) are at least the size as on the old server.
    – For each drive run the following command on the new VM server:
    netcat -l -p 9000 | gunzip | dd bs=16M of=/dev/sda
    (/dev/sda is the first drive in this case)
    – For each drive run the following command on the old server:
    dd bs=16M if=/dev/cciss/c0d0 | gzip | netcat a.b.c.d 9000
    where a.b.c.d is the ip address of the target (new/VM) server.
    Wait until done* and continue for the next drive.

    * in my case, the command on the server never returned to the command line, so it’s a good idea to start a second console on the original server and enter the command
    watch -n 10 ‘kill -n 5 USR1 ´pidof dd´

    Doing, so has the advantage that you
    1) cause dd to report it’s activity every 10 seconds, so you can see it’s progress
    2) you see, when the copying is finished.

    Using dd with a blocksize of 16M and using gzip for compression before sending the data across the network turned out to be the best solution for me. Depending on your hardware and network, you might get better results with no/different compression (e.g. bzip2) or different block sizes.

    When you see it’s finished, just press Ctrl-C on the console window, where you issued the dd command on the old server. You will then also get back to the command line on the new (VM) server and enter the next pair of commands for the next drive on both machines.

    As long as you don’t need to resize partitions and just want to replace old hardware with a VM, the advantages of this method are:
    – No need to use any disk imaging programs
    – No need to deal with parted etc
    – Direct copy from original server to new VM server

    Other than that, this is pretty much the method, that msbrentlinger already described in his post earlier here.

    On the first boot of the NEW server running as a VM, everything looked like on the real one, so i pressed ESC when Netware allowed me during boot to interrupt the start, so I found myself on the DOS prompt of the Caldera DR-DOS.

    After that I followed exactly the steps after “Edit STARTUP.NCF” on step 5 of the instructions here and got everything to work just fine.

    So thank’s a lot to all people that have contributed here and I just wanted to let you guys know, that I had to do it a bit different – but with big success anyways!

    BTW: The original Hardware was a HP ProLiant DL380 with a total of about 150G disk space.
    The VM runs on VMWare Server 1.0.10 running on CentOS 5.6 running on an Intel Modular Server.

  8. By:konecnya

    Instead of recreating the whole DOS partition from a DOSFAT based copy, I just directly fixed it with a couple simple commands (not sure if both are needed, they just made sense to me to be used as a pair)
    After you have your image on VMware but that it comes up with the DOS boot error, just restart the image booting off of a basic DOS boot ISO that has these two programs and run as follows

    format /mbr
    sys c:

    just to be sure I did run a chkdsk and a scandisk, but neither found any issues. NetWare on first boot did see some issues that it took care of and kept going just fine. And yes my head ached some dragging those commands out of very dusty memories.

    now if you happen to use a DOS that is different from the version that the server had been booting, do replace the rest of the DOS bits with the one from your ISO.

    Thank you for pointing me to MagicISO, what a useful tool to add to the kit even if I didn’t use it for this purpose. The above worked before I got that far.

  9. By:konecnya

    For full details see

    The text extract
    1. Ensure your Novell virtual machine is powered on.
    2. If you are running the GUI interface, close it. Click the Novell button > Close GUI > OK.
    3. Click VM in the virtual machine menu, then click Guest > Install/Upgrade VMware Tools and click OK.
    4. Load the CDROM driver by typing the following in the Novell console and pressing Enter:
    load cddvd
    5. Install VMware Tools by typing the following in the Novell console and pressing Enter:
    6. To end the VMware Tools install, click VM in the virtual machine menu, then click Guest > End VMware Tools Install.
    7. To go back to the GUI interface, type startx and press Enter.

    I’m not sure if this is only available on vSphere or also available on the plain ESXi so your mileage may vary