Introduction:

This procedure describes the use of Portlock Storage Manager software to transfer an image of a NetWare server to a virtual machine running on VMware server. Portlock will move the contents of the server’s partitions/pools/volumes “as-is” to the new box. There is no need to update the operating system. The eDirectory database transfers to the VM without any need to shutdown DS, or remove it from the tree. This procedure was developed by Curtis Parker, System Administrator for the State of Utah, Department of Technology Services.

Before you attempt to run a production server in a VMware server environment, you should take time to get familiar with VMware. Make sure you understand how to use VMware. Take time to read the documentation and, if possible, attend training. Also, take time to run through the procedure on test servers to make sure you understand the process. Many organizations are running NetWare in virtual machines successfully. However, we cannot guarantee that your experience will be successful.

When is this a good idea?

These are examples of situations where this Portlock procedure would be appropriate:

The existing server is stable and running well but the hardware it is running on is out of date. The server may be running some critical application for some time into the future – longer than current hardware will likely last.

The disk partition sizes on the old server are too small. Portlock affords you the opportunity to expand pool/volume sizes during the imaging operation. You can migrate to equal or larger pools, not smaller.

The server has a complex configuration that you don’t want to disturb.

Running the server in a VM allows you to backup the VM image on the host server. Depending on the size of VM’s disk partitions, this could remove the need to run backup software on the guest OS. Because VMware allows the VMs to allocate disk space dynamically as needed, the size of the backup need only be as large as the amount of space used.

You have new server hardware to replace an old NetWare server. You would like to migrate the old server to OES2/Linux rather than install NetWare on the new server but you aren’t quite ready for OES2 yet. Given adequate disk space on the new server, you could install SLES10/SP1 and VMware on it and use this procedure to move the NetWare server into a VM on the new hardware. This would buy you some time to get ready for OES2. When you’re ready, install OES2 on the new server, migrate from the VM to OES2 within the same box. Then delete the VM and add the space to the OES2 volumes.

Major hardware vendors are gradually dropping support for NetWare. Moving your server to a VM means it’s hardware will never go obsolete. Running in a VM makes the server immune to hardware obsolescence because the virtual hardware will remain the same for many years into the future even if the physical hardware changes.

When is this a bad idea?

This procedure is probably not appropriate for these situations:

You want to migrate to new server hardware with a newer version of NetWare. (e.g., from NW 6.0 to 6.5) This procedure copies an “image” of the old server to the virtual machine. The OS version cannot be upgraded during the process. However, it is possible to migrate the old server and then perform an in-place upgrade to NetWare 6.5 immediately afterward.

The old server is having some problems that you think would be cured by a fresh installation of NetWare 6.5. If it’s not stable on physical hardware, it probably won’t be stable on virtual hardware. Unless you think the problems are due to hardware. If there is corruption in the volumes or pools, the migration won’t fix it.

Downtime can’t be tolerated. The server will be down and inaccessible during this procedure. If there is a lot of data to move, it could be down for several hours. When both the old and new servers are on gigabit ethernet, the fastest transfer time we’ve seen is 40GB/hour.

You want to migrate your NetWare server to OES/Linux.

The old server(s) are running in a cluster.

There are three parts of this procedure that are critical to making it a success:

Prepare the source server with the network and disk driver load commands that will work with the VM virtual hardware. Do this on the source server BEFORE you take it down.

Configure the switch and NIC speed and duplex settings so that they will be in sync during the upgrade.

Ensure that the source server will never, ever, even accidentally, come back up on the network while its’ new clone is running in the VM.

Our Virtual Environment

Our virtualization environment is VMware Server v1.04. It provides remarkably good support for NetWare 4.x, 5.x and 6.x. We will only experiment with 5.1 and 6.5. VMware Server is currently free of charge from VMware. (http://www.vmware.com/download/server/) You will need serial numbers but you can register for them from this page and they will email them to you at no cost. VMware ESX supports NetWare equally as well as VMware Server. It has some amazing features like VMotion which will failover a virtual server to another physical server if needed.

Our host OS is 64-bit SLES 10 SP1. Most new servers you buy nowadays have 64-bit, dual or quad-core processors. The 64-bit version of SLES makes sense because it can directly utilize all the memory we give it and benefit from the high capacity of a 64-bit processor. For your production servers, you should try to get as much power as you can afford. Lots of fast processors, lots of memory and most importantly, really fast storage. For memory, reserve at least 1GB for the host OS and then as much memory as all of your guest VMs will need. When installing the host OS, be sure to use the XFS file system for the disk partition where virtual disks will be stored. XFS is optimized for handling very large files. Optimally, provide a separate set of disk drives for the host OS root partition and the partition where virtual disk images reside. This way, disk access by the VM guests will not be inhibited by the host’s access to disk. This is more critical where Windows is used as the host OS because of it’s relatively high disk usage.

For imaging software, we will use the Portlock NetWare Boot CD version 4.02. The server boots up in a runtime, Windows PE environment with Windows running in a RAM drive. The server’s file system is not modified. We like this method because Portlock is intelligent enough to recognize the NSS and traditional file system partitions, pools and volumes. We modified the ISO image of the boot CD with the license purchased from Portlock so that the software would run without any restrictions. The evaluation license will allow a maximum of a 1 gigabyte image. Alternatively, Portlock can be installed on the server and run as an NLM. In this case, it uses NetWare’s native disk and network drivers.

Preparation

Clean up

When you move to a new house, you generally hold a garage sale before you move. Similarly, get rid of all unneeded files on the old server before you migrate. Don’t forget to purge the volumes. (Wait until after the migration before selling the old server at a garage sale.) If desired, do a purge on the old volumes. Portlock Storage Manager transfers the entire pool/volume at the file system level. Everything is copied over including deleted files.

Analyze disk space needs.

When you create the VM to which the old server will migrate, you will need to define the size of the virtual disk. You need to make sure you define enough disk space to match current capacity plus any additional space you need. On a NetWare 5.1 server, use NWCONFIG – Standard disk options to discover the total size of DOS and NetWare partitions. “Standard Disk Options” shows you the DOS partition and legacy partitions using the “Traditional”, NetWare 3.x, 4.x-style file system. On my demo server, the DOS partition is 502.0 MB and the NetWare partition is 37652.3 MB. Portlock images each volume, not the whole partition. So I’ll need the size of the volumes. Choose the “NetWare Volume Options” to see the size of the traditional volumes. Also, use the NSS Options in NWCONFIG to view the size of NSS pools on the server. It is the size of the pools that is important. In my demo, I have no NSS volumes. SYS is 5000MB and DATA is 10000MB. That means I will need exactly 15,502MB on the new VM disk to maintain the same capacity. I actually want to expand to a 10GB SYS volume and 20GB DATA (DOS partitions can’t be expanded). In VMware Server 1.0.4, you define disk size in gigabytes so we’ll need to round up to the next gigabyte. So my new virtual disk will be 31 GB.

On NetWare 6.5, use NSSMU.NLM or Remote Manager to discover the size of the pools. With NSS, Portlock transfers the entire pool over so, at a minimum, you will need to provide space for the size of the DOS partition and all the pools. Check for any traditional volumes in case the server was upgraded from NW 5.x.

Provide a fast network for the migration.
To reduce the amount of time it will take to copy the data to the new server, use a gigabit Ethernet switch. If either the old or new servers don’t have gigabit interfaces, you might consider adding gigabit cards. The migration process does not have to be done on the production network. If they are connected to a switch that doesn’t support gigabit, you might consider using a gigabit mini-switch just for the migration. However, I have found that high-end switches from vendors like Cisco actually provide noticeably better performance on gigabit than the cheap little mini-switches like D-Link or Netgear.

If using Fast Ethernet, take extra care to ensure that the source server, when booting up with the Portlock boot disk will negotiate a full-duplex, 100mb/s link to the switch. A fast network is not absolutely necessary for the procedure to succeed. The source and target servers just need to communicate with each other over ip. However, Fast Ethernet will take at least 3 times longer than gigabit. Access the switch management interface to verify the speed and duplex settings negotiated by the Portlock software. This really only applies to the physical, source server because the Portlock boot CD will load the gigabit driver just fine in the VM. Gigabit requires full duplex and should generally use auto-negotiation.

Disable unneeded applications.
Look through the AUTOEXEC.NCF file on the old server and remark-out any commands that won’t apply when running in a VM. Use your judgment to determine which applications. For example: tape backup software.

Prepare the source server with the disk and network drivers for the VM.
When using this migration procedure, “almost” nothing on the source server changes. Since the server is moving to virtual hardware, it will have to load the drivers for VMware’s virtual devices. Before modifying STARTUP.NCF and AUTOEXE.NCF, make backup copies of them.

NetWare 5.1, 6.0 and 6.5 all use IDEATA.HAM and LSIMPTNW.HAM disk drivers and PCNTNW.LAN network drivers in VMware virtual machines. For platform support, NetWare 5.1 and 6.0 use the MPS14.PSM driver while NetWare 6.5 uses ACPIDRV.PSM. All of these drivers are most likely already on your server. You should use the version that comes with whatever support pack level is on your server. After running md5sum on the drivers from each version, I found that MPS14.PSM and PCNTNW.LAN are identical across all three versions of NetWare. The other drivers (LSIMPTNW.HAM, IDEATA.HAM, etc) are different.

NetWare 5.1 and 6.0 store and load disk and PSM drivers from C:\NWSERVER. They load network drivers from SYS:SYSTEM. They store unused drivers in C:\NWSERVER\DRIVERS. When you use the NWCONFIG tool to install the drivers, it copies them to C:\NWSERVER. NetWare 6.5 stores and loads all drivers in C:\NWSERVER\DRIVERS. Make sure the needed drivers are in their proper places for your version of NetWare.

Since NW 6.5 loads the drivers from C:\NWSERVER\DRIVERS, there is no need to copy them first. On a NetWare 5.1 or 6.0 server, the disk and PSM drivers are probably not in the C:\NWSERVER directory. They are placed in C:\NWSERVER\DRIVERS when NW 5.1/6.0 is installed. You can manually copy them from the DRIVERS directory to the NWSERVER directory or use NWCONFIG to copy it. To do so:

These load lines were all taken from fresh installations of NetWare 5.1/sp8, NetWare 6.0/sp5 and NetWare 6.5/sp7 into new VMs on VMware Server 1.0.4. Enter these into the STARTUP.NCF and AUTOEXE.NCF, respectively and remark-out the old load/bind commands.

If you use the INETCFG tool to configure networking, then simply disable the current driver (by pressing tab on the driver under “Boards” or deleting it altogether). Then add the PCNTNW driver using slot 3. Add a binding to PCNTNW under “Bindings” using the same ip address. If the server will have a new ip address in the VM, this is a good time to setup the new address, mask & gateway. In that case, be sure to change the default gateway under “Protocols”.

FATFS.NLM
When NetWare 6.5 boots up, it performs a local drive check. It does a CHKDSK-like test on the DOS partition. I found in my testing that sometimes this process abends the server running on VMware and halts all further loading of the OS. To resolve this, rename the FATFS.NLM in the C:\NWSERVER directory. This will cause the OS to bypass the local disk check and continue loading.

Rename SERVER.EXE
After this procedure is complete, you will have an exact clone of the source server running in a VM. It is EXTREMELY critical that the source server not come up on the network and start communicating with other servers in the NDS tree while the new clone is running. Similar to Dr. Emmit Brown’s warning to Marty McFly in the movie, Back to the Future: “It could disrupt the space-time continuum.” In this case, it would be the NDS tree continuum. Having two clones of the same server on the network can cause severe problems in the NDS tree. Novell support engineers have told of situations where this has happened. Certain objects replicated by the servers, including OU objects have been renamed and/or changed to unknown objects. Of course, users under those OUs were not able to login. Only tree surgery by a Novell engineer will repair the damage. Now that you have been warned, it is your responsibility to make sure it doesn’t happen.

I recommend that you rename the SERVER.EXE file on the source server before the migration just to make absolutely sure that both servers don’t boot up on the network. After the image copies over, we will simply rename SERVER.EXE back to normal on the VM when we boot the server. To rename the SERVER.EXE and FATFS.NLM files, boot the server to a DOS prompt by hitting F8 when the server boots and shows the message, “Starting Caldera DR-DOS”. Answer “Y” to the prompts but answer “N” to loading SERVER.EXE. Then use these commands at the DOS prompt:

cd \nwserver
ren server.exe server.ex
ren fatfs.nlm fatfs.nl

You could also load DOSFAT.NLM which will mount the DOS partiton as a volume named, “DOSFAT_C”. Then you can access the C:\NWSERVER directory from a client. There are a also few file-manager utilities you can load at the server console that will allow you to rename files from the server console: JCMD.NLM, NWCC.NLM, FILER.NLM and TOOLBOX.NLM which can be downloaded from netwarefiles.com. FATFS.NLM only needs to be renamed on NetWare 6.5 servers.

Create the VM
8.1.When creating the new virtual machine in VMware, use these options and parameters:

Use a “Typical Configuration”

The Guest OS should correspond to the version of Netware on the source server.

The location of the virtual machine should be on the XFS partition you created for VM images.

Use bridged networking for best performance.

Plan the size of the virtual disk. It must be at least as large as the size of the DOS partition, SYS pool and any other pools you plan to migrate from the source server. I’m not referring to actual “used” space on the source server, but rather the capacity of the pools. Also, add any additional capacity that you want the Portlock software to add to the NSS pools during the migration. Portlock can increase the size of NSS pools but not reduce them. (It can, however, reduce the size of traditional volumes.) Earlier, we calculated the size of our new disk to be 31GB.

You will need to decide if you want to allocate all the disk space now. If you don’t allocate all space now, it will create a small disk image file and increase the size of the file as needed by the guest OS. Performance is a little better if you pre-allocate disk space now. It will take about 1 minute per gigabyte to create the virtual disk image. If you plan to backup the server image on the host server, then pre-allocating the disk space makes for very large images to back-up.

Important Note: According to Novell Support, if you will store your virtual disk on a partition formatted using the OCFS2 file system, you must pre-allocate disk space for the VM. See details at the end of this document.

Modify the CD-ROM options leaving “Connect at power on” checked. Rather than the physical device, point it to the ISO image of the Portlock boot CD. (You must have already modified the ISO image with the license you purchased from Portlock.)

Migration

Boot up the source server with the Portlock Boot CD v4.5. This runs Portlock Storage Manager version 4.5.

Once booted, the Welcome screen will show. On the left-side navigation bar, click on “Network”, and then, “Network Configuration”.

The Network Configuration dialog will show DHCP is enabled and the ip address that it acquired, if any. To set a static ip address, click on the Advanced tab and then the “Use the following ip address” radio button. Enter the ip parameters and click OK.

Enter the Network Configuration dialog again to make sure it shows the new ip address.

On the left navigation bar, click on “Utilities”, then “Command Prompt.”

Run IPCONFIG to check the ip address. Also do a ping to make sure it is communicating on the network. Exit the Command Prompt window.

On the left navigation bar click on “Storage,” then “Portlock Storage Manager.”

Press any key to by-pass any warning screens and the license screen.

Choose “Cancel” when asked to check for updates.

Management Mode is “Manage Local System”

The type of disks to manage is “Manage Physical Disk Drives.”

From the menu selections, choose NetWare and the version of the source server.

From the Main Menu, choose, “Image Commands.” This is key. The source server MUST do the imaging. The target server will do a restore of the image.

From the Image Menu, choose “Image entire system.”

Portlock displays all the partitions, pools and traditional volumes that it finds. Leave the status of the FAT16 partition and NetWare volumes to “IMAGE”. If it shows an HP configuration partition around 30MB in size, select that and hit F5 to skip it. Press Enter to continue.

When prompted to purge volumes, select “Do not purge any volumes”. We’ve already cleaned up and purged. Besides, I’d rather trust NetWare to do the purging rather than Portlock.

From the “Select Image Destination” menu, choose, “Write image to a TCP/IP link”.

Choose “Disable Software Write Compression” for the Compression Mode.

The source server will act as the TCP/IP Server. It doesn’t actually matter whether it is server or client. Since this is the first, it will be the server.

Next, the ip address and port that this Portlock server will listen on. This is filled in for you. Leave it as-is, remember the ip address and hit Enter.

Target Server

If you haven’t already, power-up the new VM that you have already configured. If configured correctly, it will boot up with the Portlock boot CD.

Configure the network as needed.

Click on “Utilities” and “Command Prompt.” Run IPCONFIG to check your network configuration. Ping the source server to make sure you have communication. Close the Command Prompt window.

Select the OS and version to match what you selected for the source server.

It asks if you want to create a master boot record on the disk. Answer, “Yes”. We will need it.

From the main menu, choose “Restore commands”

For the image source choose, “Read image from a TCP/IP link”

Choose TCP/IP client mode.

Enter the ip address of the source server and press F10 to connect.

It will show the DOS partition and NetWare volumes that you selected on the source server. Hit Enter to restore.

Storage Manager now shows the disk devices it sees and what is on them. It should show an MBR and the remaining free space. Hit Enter.

It will prompt for you to enter the size of the DOS partition. The default should be the current size. Make sure it is between the minimum and maximum.

You will restore the DOS partition at offset 0. Hit Enter to begin the restore. The DOS partition should only take a few seconds to restore.

Traditional Volumes

Because we are restoring NetWare 5.1, our SYS volume uses the traditional NetWare file system. It prompts for the Volume Restore Method for the SYS volume. We have not yet created a partition for our SYS volume. We will need to decide how to partition for our two volumes. If SYS was traditional and DATA was NSS, we’d create one partition sized at 10GB for the SYS volume. Since SYS and DATA are both traditional file system, we can create one partition for both. Choose “Restore volume to a new NetWare partition.”

Select the disk device, then the offset.

Now it prompts for the size of the partition for our traditional volumes. It will default to the maximum size. Since we’re putting both volumes in the same partition, Hit F10 to use all disk space.

Now it prompts for which partition to restore to and defaults to the one we just created. Hit Enter.

Now it asks for the size of our SYS volume. We’ll enter 10000 to create a 10GB volume. Press Enter. Leave the name as SYS (if you want it to work). Press Enter.

It will restore the SYS volume. On gigabit ethernet, speed should be around 10,000 KBS. If the speed gets down below 1,000 KBS, you may have an ethernet duplex mismatch.

When it finishes SYS, it then asks for the volume restore method for DATA. Since we created one partition for both, we’ll choose, “Restore volume to an existing NetWare partition.” It shows the only partition there. Hit Enter.

Now it asks for the size of the DATA volume. Portlock is able to shrink traditional volumes so you can enter a smaller number if desired. We’ll enter the maximum to use the remaining disk space. Hit Enter to start restoring the DATA volume.

NSS Volume:

If you’re migrating a NetWare 6.0/6.5 server with NSS pools rather than traditional volumes, the process is much simpler. Portlock dynamically sizes the NW6 master partition to contain the NSS pools as you restore them. Thus, it doesn’t bother you about partition size. It just expands it as needed.

Leave the SYS volume name alone and press Enter.

Enter the new size of the NSS SYS pool. By default it fills in the current size. If you allocated more space for the SYS pool when you defined the size of the virtual disk, enter the new size in megabytes.

The next screen shows the destination drive. Hit Enter. Hit Enter again on the starting offset.

Restore the remaining NetWare partitions.

When complete, POWER OFF THE SOURCE SERVER.

Click Reset on the target VM.

Post Migration

VMware Tools

When NetWare runs in a VMware VM, it will consume all the CPU time that VMware will give it. As a result, VMware will show high utilization even when CPU utilization on the NetWare guest OS is low. VMware has resolved this with VMware tools. When you install VMware Tools on a NetWare VM, it installs VMWTOOL.NLM into sys:system, adds it to the AUTOEXE.NCF file and loads it. It installs other files as well so don’t think you take a shortcut by just copying VMWTOOL.NLM to the server and loading it manually.

The most important thing is that it idles the CPU in the VM to match the CPU utilization in the NetWare guest OS. To illustrate, run the “top” program on the Linux host while the NetWare guest is running without VMWTOOL running. You’ll see a process called “vmware-vmx” consuming a lot of CPU time.

For NetWare, VMware Tools comes in the form of a CD-ROM ISO image named netware.iso. On Linux, it is found in the /usr/lib/vmware/isoimages/ directory.

To install VMware Tools, first switch to the console view of your NetWare VM. Make sure the NetWare OS is up and running.

Click on the VM menu on the VMware console.

Choose “Install VMware Tools.” This has the effect of mounting the netware.iso image as a CD in the NetWare guest OS. Like sliding the CD into the virtual CD tray. NetWare 6.5 guests will auto-mount the CD as a volume named, “VMWTOOLS”. On NetWare 5.1 and 6.0 servers, you will need to load CD9660.NSS to mount the CD.

Type this command at the console: VMWTOOLS:\SETUP.NCF

Now click on the VM menu and choose “Cancel VMware Tools Install…” This will remove the virtual CD from the virtual CD drive.

Timesync

Timesync becomes a major challenge when running NetWare on VMware. For whatever reason, the CPU clock runs faster in a VM than on the host hardware. This will cause timesync to get out of whack. After Googling and consulting with experienced sysadmins, these are my recommendations:

Turn off Dynamic Frequency Scaling in SLES power management. Just turning off the powersaved process didn’t seem to be enough. But changing the power scheme to “Maximum Performance” seemed to help.

Start yast2 and run the Power Management applet.

Set the Energy Saving Schemes to Performance for both AC and battery-powered modes. (Note: if your production server is capable of running on batteries, then STOP USING LAPTOPS AS SERVERS!)

Click on Edit Schemes. Choose the Performance scheme and click Edit.

Change Frequency Scaling to “Maximum Performance”.

Click Next, Next, OK, then Finish.

Set the timesync type for the NetWare guest to Secondary and point it to the Single or Primary time server for the tree using NTP. SINGLE and REFERENCE time servers read the hardware clock at each polling loop. PRIMARY and SECONDARY servers set the hardware clock. Therefore, it is best to use a physical server (a non-VM guest) as the SINGLE or REFERENCE time server. Use these commands at the server console:

The “timesync debug” command will open up a timesync window that will show the amount of time correction on each update. “Set timesync debug = 0” will turn it off. The “restart flag” command restarts timesync polling with the new parameters.

Do not use the VMware Tools synctime feature. Make sure that “tools.syncTime = “FALSE” is set in the vmx file for the NetWare VM. At the server console you can use the command: “VMWTOOL synctime off” to do this.

Backing Out
What if you have to go back to the old server? You tried to make it work. Something went wrong. The new server just won’t run in the VMware environment. Amidst the panic and confusion, don’t forget: DON’T LET BOTH SERVERS RUN ON THE NETWORK AT THE SAME TIME!

First, go to the VMware console and power off the VM. Then click the VM menu and choose “Delete from Disk”.

If for some reason, you want to keep it, then rename server.exe to something else to keep it from booting up.

Re-connect the old server to the network and boot it up. It will boot to a DOS prompt because server.exe was renamed. Change to the C:\NWSERVER directory and rename it back.

While still in DOS in the C:\NWSERVER directory, make a copy of startup.ncf with the VMware load lines in case you want to try it again in the future.

Copy your backup copy of the original, working startup.ncf to startup.ncf in C:\NWSERVER. If you didn’t make a copy, then type “edit startup.ncf”. Remark-out the commands you inserted for VMware and un-remark the original commands.

After you make absolutely sure that the NetWare VM is powered off, startup server.exe.

After it comes up, you’ll need to put the network drivers back to the way they were. If you did this in INETCFG, then go to Boards, and hit the Tab key on the PCNTNW driver to disable it and Tab on the old driver to re-enable it.

If it changed, change the default gateway back by going to Protocols, TCP/IP and “LAN Static Routing Table”. Re-initialize system to put the changes into effect.

If the load and bind commands for the network drivers are in AUTOEXE.NCF, you’ll need to change them back there and reboot the server.

VMware Console Browse Bug
During my testing, I found a problem with the VMware console. Clicking on the Browse button when in the Open VM dialog or to browse for a CD ISO image would hang the VMware console and force you to kill the process and restart it. I found the solution here: http://www.novell.com/coolblogs/?p=960

These are the commands I ran on my test server (SLES10 SP1 x64 and VMware Server 1.04) to fix the problem:

Performance testing
So if you actually move a production server to a VM, how will it perform? Does running in a VM with a virtual disk impose a large performance penalty. I did some crude, very simplistic testing. I used a laptop running Windows XP to connect to different servers over a gigabit ethernet network. I used this batch file to copy a 100MB file to the server:

ECHO %TIME%
COPY 100mbFile.txt F:\
ECHO %TIME%

After the batch file ran, I calculated the difference between the first time and second time stamp. These were the results:

OCFS2 and sparse files
There is an issue with the OCFS2 file system and sparse files. If you create a VM disk on an OCFS2 formatted partition, you must pre-allocate the virtual disk space or risk corruption. When you create a VM and don’t pre-allocate the disk space, that creates a sparse file. Sparse file support is included in version 1.3.9 of OCFS2. 1.3.9 is included in SLES 10 SP2 or the 2.6.22 kernel. If you have an OCFS2 file system that was created with an earlier version, after you install SP2 with OCSF2 v1.3.9, you can enable sparse file support with this command:

tunefs.ocfs2 --fs-features=sparse,unwritten <device>

OCFS2 is the Oracle Clustering File System. You would use it in conjunction with an OCFS2 cluster to allow multiple VMware servers to access the same storage on a SAN simultaneously.

(0 votes, average: 0.00 out of 5)You need to be a registered member to rate this post.

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.

A colleague of mine who manages a few VMware ESX systems said that he solved the problem of NetWare VM timesync by changing the CPU power mode in the BIOS of his HP servers. In the F9-setup utility on a G5 series server, choose: System Options, Power Regulator for Proliant, HP Static High Performance Mode. He also changed the timesync polling interval on the NetWare guest to 60 (from the default of 600), though we’re not sure that’s necessary. We haven’t tried this on G4 or older servers so I’m not sure if this option exists. I have no idea of what the equivalent is on Dell or other hardware. If you know, post it!

I tried this on one of my own servers running VMware Server 1.5. Before the change, the timesync debug screen showed time adjustments of -200 to -3000 milliseconds at each polling interval. After the change, adjustments were around +-50 milliseconds. I did not change the timesync polling interval on my NetWare guest.

The two most important factors in Time (not) Sync’ing I have found with respect to Guest OS’s are the CPU speed and the prior mentioned PIT clock setting.

The problem we experienced was inconsistent time tracking in the Guest OS, and we saw the linux guest OS was not seeing the correct CPU speed. This was using VMWare Server v1.x so this may have been corrected in v2.x. The change we made in the file ‘/etc/vmware/config’ was to add: