With everyone in the world converting from “Physical” server to virtual, and in our attempts to use less electricity, less cooling, and just being “Greener”, I decided to look at Migration Specialties Avanti. You can find Migration Specialties at www.migrationspecialties.com .
We currently have different AXP servers, but for my test, I will convert a Dec Personal Workstation 500au that had narrow band scsi drives, a tape drive, a CD-ROM with 512Mb of memory. To make this harder, I want the final solution to run on VMware vSphere V4.1 ESX server.
Before I go any further, I want to thank Bruce Claremont of Migration Specialties. He is a true professional, always willing to help, and willing to listen. His expertise in this matter has proven invaluable. I hope to complement his expertise with a few gotchas I found that may effect a system going to Virtual Windows instance running on top of VMware vSphere 4.1 servers.
The first thing I had to do was load a Windows 7 Pro x86_64 system. You will want to build it with the primary “C” drive in thick format and I built two more drives in thin format for the AXP’s system drive and backup drive. I got W7 Pro loaded, and assigned the USB key on ESX to the W7 system. Avanti, from Migration Specialties, uses a USB key to allow for different components of Avanti to be turned on. Since I wanted my emulated AXP server to have 512Mb instead of 128Mb, which FreeAXP [Avanti’s freeware version and limits 128Mb memory] supports, I needed to purchase 10 units of license. The USB key keeps track of how the “units” are used.
Loading the Avanti software was very simple on the Windows 7 Professional 64bit OS. It loaded in a few minutes, and I was ready to build my configuration. The Avanti system is laid out in a simple to follow method, if you’ve been around Alpha Server for years, this will be the simplest AXP Alpha server you will ever build. In my case, I added a KZPAA SCSI adapter, added two HSZ virtual drives [NOTE: Avanti has a bunch of canned DEC type drives, so if you must emulate a RZ28, RZ29, many more, you can]. The HSZ allows for any size I want to create. My original system drive was 9Gb, I wanted 30Gb, and with the HSZ I was able to add it as DKA0. I also put the HSZ system drive on it’s own Virtual disk drive because in Avanti you can pick any Windows based drive and directory to put your .IMG files into. NOTE: for Physical server, you could IMG files on different disks for optimal IO speed and prevent IO conflicts. In VMware, you can do the same with VMFS file folders based on different drives.
NOTE: Avanti supports RAW mode access, this means that if you had a physical OpenVMS drive, you could connect it to the physical server and let Avanti talk to it directly. Great if you really want to connect old SCSI drives and copy the data off to the faster, newer SATA or SCSI Ultra320 drives. Another reason you could do this, you want Windows NTFS to stay out of the way for the fastest IO possible.
I also created a CD-ROM and attached it to the Windows 7 CD-ROM device. Lastly, I create a 90Gb HSZ drive for backups [again, another Windows drive separate from the system drive, just because I wanted to split off the backup .IMG file away from the system .IMG file]. I added this as DKA300 as seen by the Virtual AXP server.
In order to move my data, I kind of cheated… Or did it the hard way… Or should I say, I’m sure there’s a much easier way to do this, and I’m open to a better/faster way. On the Physical AXP server, I backed up OpenVMS to a container file using VMS Backup with the “/image/ignore=interlock” switches. I then loaded OpenVMS 8.4 from the CD-ROM onto the system drive, just loading enough network, Decnet and TCPIP, onto the virtual Avanti AXP server I had created. Once I booted up the virtual server after loading OpenVMS 8.4, I was able to setup decnet and tcpip with temporary addresses. I then FTPed the container file of the backup of the physical server to the virtual servers “backup” drive.
To create the container file, I added a physical SCSI hard drive, dka100:, on my physical DEC Workstation as a temp backup drive. My system drive was a shadow set drive, DSA0, which consisted of DKA0: and DKA500:. To back it up:
init dka100: backup
mount dka100: backup
create/dir dka100:[backup]
backup/image/ignore=interlock dsa0: dka100:[backup]system.bck/save/nocrc
Once I had the container file on the Virtual AXP backup drive [called dka300 in this case], all I had to do was boot the CD-ROM to get a DCL command line, mount the Virtual AXP’s system disk foreign, the backup disk in normal mode and do a restore:
mount/for dka0:
mount/over=id dka300:
backup/image/verify dka300:[backup]system.bck/save dka0:/init
I then shutdown the Virtual AXP. Shutdown the Physical box [don’t want more than one box at the same IP address on the network]. Booted the Virtual AXP and…. VOILA! Up comes my physical box data on the Virtual AXP Alpha server.
Time for testing…
I found issues with the network card, but these are documented in the Migration Specialties PDF files. I found that on W7, you want to create two separate NIC cards. One for Windows 7 to use, one for Avanti/AXP virtual server to use. In VMware, you want to create the Avanti NIC to point to it’s own switch, with Promiscuous mode turned on for the NIC card [not for the switch!!! Just the NIC card itself]. The reason has to do with virtual MAC addresses and allow the Avanti/AXP virtual server to get it’s MAC address published on the physical NIC card in the VMware server.
Once I got the network stabilized, overnight I found the Avanti/AXP server losing it’s network. Every time I rebooted, it came right back up… I looked around and found that Windows 7 was going to sleep mode! Oh crud, I had to tell Windows 7 that it’s never to sleep, never to shutdown the LAN cards for power, never to do anything that will put Windows 7 in to hibernation.
AH, now the Virtual AXP system is working perfectly. Time to test speed:
On the physical server, I found the speed of the test VUPS.COM file to be 120 VUPS [or Vax Units of Performance – Which, in the old DEC world, use to be called Vague Units of Performance]. The same command on the virtual server yelded only 28 VUPS. Considering the VMware server was 2.6Ghz, based on VUPS, we went from 500Mhz [120 Vups] down to 116Mhz [28 Vups]. I know, it’s a virtual inside of a virtual… It’s about a 4:1 relation.
One funny thing about the virtualization, in OpenVMS, the processor never sleeps. Windows with Intel/AMD, allows for the CPU to go to sleep. OpenVMS, instead, spins on the NULL process [or in my case, DNETC calculations]. I found that one processor of my Virtual Windows 7 system pegged at 100%. This is just the nature of the AXP Alpha OpenVMS beast. So, if you notice the single processor on Windows 7 getting nailed to 100%, it’s normal.
How about disk speeds… The physical server could do disk to disk backups in 2 hours. The Virtual server, 20 minutes! WOW.. We gained serious speeds in the disk I/O, which is expected because the physical servers used old narrow SCSI and the new VMware ESX server had SATA 6G speeds. That was the first time while doing a “Monitor System” on the OpenVMS virtualized server went complete CPU bound during a backup.
Overall, it works for what I want. If I had gone to a physical Windows 7 server, I’m sure the CPU would have been closer to 1:1 while still keeping the fast IO response times I’m seeing. Maybe if I get a chance, and a spare key, I’ll test it using the .IMG files from my virtual virtual server 🙂 . Again, I want to thank Migration Specialties for a great product and look forward to using Avanti now and going forward.
END NOTE: After talking with Bruce, if both systems, Physical and virtual, have DECnet working, you just backup across DECnet [saves having to create a local save set, then FTPing the file over]. And, I did not purchase the JIT [Just In Time] addition for Avanti, this should have resulted in a 2:1 in speed instead of the slower 4:1 that happen to me. So, if your system speed is critical, use a physical windows system with JIT, you’re going to be closer to 1:1 or maybe even end up with the virtual AXP server running faster then the Physical AXP server was running. Overall, Avanti is a great way to go Green and still keep your OpenVMS systems running! Thanks Migration Specialties!
ADDITIONAL INFORMATION: As of a week later, the AXP virtual system running OpenVMS is rock solid. I’m not use to the full backups getting done in under 30 minutes, it’s a speed increase that I’m very happy to have happen. And to have the entire W7 VM snapshoted, I have the best of both worlds for disaster recovery because I can recover the entire W7 VM that runs Avanti or individual files for OpenVMS very quickly. Because of this product, I believe OpenVMS has a new hardware home, and as older Alpha systems become next to impossible to replace/support, OpenVMS AXP systems can continue to live productive lives on Intel/AMD hardware.
HISTORY: Carl C. has been working with OpenVMS since V1.1 on a VAX 780 back in the early 1980s. Carl has also been working with VMware since ESX 3.0.