Can any other OS do this?

[Andreas Fassl]

Hi there,

just got a dead AXP system from a desperate customer. And this is some kind of a success story I want to share.

The machine (an EV4 processor based system) was running for now nine years on the same hardware, last installation change end of 97.
eleven machine checks in this time, as usual the decw$server process. With an appropriate patch those wouldn't have happen.

Made an image backup (which OS does really offer an image backup so easy to handle) and an image restore to newer hard disks. (two commands, no extra boots).

Thereafter - oh good - the system refused to boot. Reason: OS version too low for hardware. No problem - bootet VMS 7.3, did upgrade, automatic parameter change, made two changes in the system startup procedure (to set correct mounts) and ... system came up as usual.

Had so many nightmares with this scenario on this OSes:
- Linux (RedHat/Fedora)
- Windows (Server and Workstation)
- Solaris (Sparc)
- HPUX
- AIX

With these OSes you will end up with a complete new installation.

Concluding question:

Can any other OS do this?

:-)

[Uwe Zessin]

I don't want to downplay your work / VMS' autoconfigure process and its BACKUP utility (met it first in VAX/VMS V3.0 and started to like it, although that is a different story...), but it looks like you had it quite easy, because:
- no change in LAN adapter name
- same license class
- something else I have forgotten ;-)


In the past few weeks I have successfully moved Windows NT, Windows 2003 and Linux servers from physical hardware onto VMware ESX server. We had:
- different mother board and different processor
-- Pentium III vs. XEON
- different LAN adapters
-- DECchip vs. AMD PCnet/VMware vmxnet
- different storage adapters
-- boot from IDE, data on Adaptec SCSI vs.
-- VMware emulated BusLogic or LSI logic HBAs

Certainly this was some more work, because the hardware was more different, but a modern image utility is a nice counterpart to OpenVMS BACKUP.

[Wim Van den Wyngaert]

Also check this http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=1038607
Again the wise words of Uwe.

We still have started the exercise (I'm a managed service).

Wim

[Robert Gezelter]

Andreas,

OpenVMS is pretty alone in that area. Most significantly, other OS's lack logical names, and must therefore use some form of virtualization approach to achieve the configuration independence (a fact that I noted in one of my chapters in the Handbook of Information Security, see http://www.rlgsc.com/hinfosec/hinfosec.html for a description of the book).

I have also had the experience of transitioning systems from one set of hardware to another with only the slightest degree of disruption, even though the hardware environments are dramatically different, it is truly a pleasure.

- Bob Gezelter, http://www.rlgsc.com

[Uwe Zessin]

Logical names (and logical name tables) are truly a powerful mechanism. I was able to set up multiple test instances of our software environment that way - a bit similar to RDB's multi-version support.


On the other hand: many operating systems have some kind of abstraction which has nothing to do with virtualization and can easily deal with changes to devices.

On Unix/Linux, you can mount a file system somewhere into the tree (/boot, /var, /mnt/cdrom) and it does not matter what the device's name is (/dev/hda, /dev/sda, ...). If the device name changes, you change the device name in the data file for the mounts (/etc/fstab) but keep the mount point (/var). Red Hat Linux puts a file system label (similar to the ODS volume label) into FSTAB and lets the mount command find out on which device the file system exists.


Tru64 Unix does persistent LUN binding to make sure that the device name (dsk3) does not change when a LUN is moved to a different target/LUN address. Should the LUN get a new WWN identifier, it gets a new name, but you can rename it back to dsk3.
I am not a Tru64 expert, but I know they have a thing called the 'generic kernel' which, I think, includes all supported device drivers so it can boot on any supported hardware.
Maybe Hein can add to this...


Windows maps a drive letter to a file system (OK, you have only 26 ;-), but you can also use Unix-style mount points. The SCSI address does not matter at all.
A Windows OS image was never meant to be moved between computers, but several vendors (including HP) have started to provide migration tools.

[Jan van den Ende]

Andreas,

although the points put forward by the other posters do mean something, I still tend to highly concur with you:

There really is no system where such thing are SO EASY!!

"OpenVMS, when downtime is NOT an option!"

(but even VMS can be, and sometimes IS, configured apparently to specifically PREVENT doing things the easy way).

Proost.

Have one on me.

jpe

[Peter Zeiszler]

Congratulations on a nice migration. Some are a pain, others are cake. I have had to rebuild systems on new hardware with pain and I have had it go smooth.

None of the other OSes I have played with are this easy to me. The best you can hope for is to get to a stable install then reinstall from tape. Sometimes reinstalling without restore from tape is a good thing -- helps cleanup. :D