Migration from VMWare PRo 17.5.2 to ESXi 8.02

[brianreiter]

Is there a guide to migrating an OpenVMS VM from VMWare Pro 17.5.2 to ESXi 8.02?

So far, I've tried 2 methods:

1) From VMWare, export to OVF and then import from the ESXi server.
The disks weren't migrated properly, appeared as thinly provisioned and on the wrong controller (DKB rather than DKA)
Boot failed fairly quickly


2) From VMware use the "Upload" option
Disks appeared to be correct (pre-allocated).
Still on the wrong controller (DKB0) but seemingly correct in the configuration (SATA 0:0 etc.)
Boot failed fairly quickly.

We're in the middle of migrating a test system from a laptop to a server so we can take it to a customer to demonstrate that virtualisation of the existing system is viable.

Migration of Windows and linux VMs from VMWarePro to ESXi (as an OVF export) went without a hitch.

[whcox53]

When you say "the boot fails fairly quickly", it would help to know what the failure message was.

[brianreiter]

Looking at that now...

Code: Select all

Booting...

%%%%%%%%%%% VSI OpenVMS (tm) x86-64 Console %%%%%%%%%%%


_______________________________________________

      THE GUEST CONSOLE HAS BEEN SUSPENDED
     USE A TERMINAL UTILITY FOR OPA0 ACCESS
_______________________________________________

VSI Primary Kernel SYSBOOT

%SYSBOOT-I-VMTYPE, Booting as a VMware (tm) Guest


        VMS Software, Inc. OpenVMS (TM) x86_64 Operating System, E9.2-3
                    Copyright 2024 VMS Software, Inc.


%SMP-I-CPUTRN, CPU #1 has joined the active set.

VSI Dump Kernel - Handles Shutdown/Reboot/Crash Dumps
^[[?6c^[[?6c^[[?6c
%SET-W-NOTSET, error modifying OPA0:
-SET-I-UNKTERM, unknown terminal type
The SET TERMINAL/INQUIRE command failed, connection may not be using CHAR MODE.

**** OpenVMS x86_64 Operating System E9.2-3   - BUGCHECK ****

** Bugcheck code = 000003C0: SSRVEXCEPT, Unexpected system service exception
** Crash Time:            19-SEP-2024 15:55:29.00
** Crash CPU: 00000000    Primary CPU: 00000000    Node Name: HATMS
** Highest CPU number:    00000001
** Active CPUs:           00000000.00000003
** Current Process:       "SYSINIT"
** Current PSB ID:        00000001
** Image Name:            SYSINIT.EXE

** No useable error log dump file found.
%SYSTEM-F-ACCVIO, access violation, reason mask=04, virtual address=000000000000
0010, PC=00000000800068DF, PS=0000001B


  Improperly handled condition, Dump Kernel aborting
    Signal arguments:   Number = 0000000000000005
                        Name   = 000000000000000C
                                 0000000000000004
                                 0000000000000010
                                 00000000800068DF
                                 000000000000001B
    Register dump:
    RAX = 0000000000003600  RDI = 0000000000000080  RSI = 000000007AD38584
    RDX = 0000000000000010  RCX = 0000000000000010  R8  = 0000000000000004
    R9  = FFFFFFFF80D39A80  RBX = 0000000082000000  RBP = 000000007AD38DF0
    R10 = 000000007AD38584  R11 = FFFFFFFFFFFFFFF5  R12 = 000000000000A300
    R13 = 000000000000A3D0  R14 = 0000000082000000  R15 = 0000000000000000
    RIP = 00000000800068DF  RSP = 000000007AD386E0  SS  = 000000000000A4E0
                    Call Frame Chain:

                    Depth        RIP
                    ----- -----------------
                    0     00000000.800068DF
                    1     00000000.80004364
                    2     00000000.8005C1B8
                    3     00000000.7AE003DC

  Process activated images:

  Image / Link Time / Type     Start VA           End VA         Image Offset
  ------------------------ ----------------- ----------------- -----------------
  DCL
  20-JUN-2024 11:56:20.17
                      Code 00000000.7AD9A000 00000000.7AE502BF 00000000.80000000
                      Code 00000000.7AEBA000 00000000.7AEBAE17 00000000.0002C000
  SYS$DUMP_KERNEL
  20-JUN-2024 11:56:19.95
                      Code 00000000.80000000 00000000.80062357 00000000.80000000
                      Code 00000000.00018000 00000000.00018267 00000000.00018000
  SYS$DUMP_KERNEL_SHR
  20-JUN-2024 11:55:37.79
                      Code 00000000.80B02000 00000000.80B048EF 00000000.80000000
                      Code 00000000.0011E000 00000000.0011E5F7 00000000.0000A000
  DECC$SHR
  20-JUN-2024 11:55:21.96
                      Code 00000000.8052E000 00000000.8096B79F 00000000.80000000
                      Code 00000000.000F0000 00000000.0011567B 00000000.00028000
  DPML$SHR
  20-JUN-2024 11:55:18.41
                      Code 00000000.8019A000 00000000.8024018F 00000000.80000000
                      Code 00000000.0007A000 00000000.00088DB7 00000000.00022000
  CMA$TIS_SHR
  20-JUN-2024 11:55:15.93
                      Code 00000000.80288000 00000000.8028BBD7 00000000.80000000
                      Code 00000000.00096000 00000000.00097F53 00000000.0000E000
  LIBRTL
  20-JUN-2024 11:55:14.41
                      Code 00000000.802B0000 00000000.8045C3A7 00000000.80000000
                      Code 00000000.000C2000 00000000.000C960B 00000000.0002C000
  LIBOTS
  20-JUN-2024 11:55:13.91
                      Code 00000000.80162000 00000000.801720CF 00000000.80000000
                      Code 00000000.00058000 00000000.00059EAB 00000000.00004000
  DISMNTSHR
  20-JUN-2024 11:55:20.22
                      Code 00000000.8014A000 00000000.8014B62F 00000000.80000000
                      Code 00000000.8014C000 00000000.801532D7 00000000.80002000
                      Code 00000000.80158000 00000000.8015914F 00000000.8000E000
                      Code 00000000.00054000 00000000.000541C3 00000000.0000E000
  MOUNTSHR
  28-JUN-2024 10:47:12.76
                      Code 00000000.800B6000 00000000.800B709F 00000000.80000000
                      Code 00000000.800B8000 00000000.8010118F 00000000.80002000
                      Code 00000000.8011C000 00000000.8013B2FF 00000000.80066000
                      Code 00000000.00046000 00000000.00047123 00000000.0002E000
  SHRIMGMSG
  20-JUN-2024 11:56:32.60
  DECC$MSG
  20-JUN-2024 11:56:20.05


%SYSTEM-W-NOMSG, Message number 00003600
Something has gone wrong. Attempting to restart the system...

Restarting the system...

The VM was working. I'm hoping there's something obvious I've not done somewhere along the line.

[earlem]

This looks like the same problem as seen in "Crash on installation kit media boot" https://forum.vmssoftware.com/viewtopic.php?f=37&t=9208
where the cpu is missing features.

I'd suggest that you request the the patch (see https://forum.vmssoftware.com/viewtopic ... =20#p22317) and see if that solves the problem.

[hb]

This looks like the same problem as seen in "Crash on installation kit media boot" https://forum.vmssoftware.com/viewtopic.php?f=37&t=9208
where the cpu is missing features.

No! The footprint is totally different. Please, before making such statements compare what's in the provided log.

There is an SSRVEXCEPT bugcheck triggered by code in SYSINIT.EXE. However the reported IP is not in SYSINIT.EXE, it is in SYS$DUMP_KERNEL.

I suggest to enable "Display Detailed SYSINIT Messages" in the VMS Boot Manager with the SYSINIT command.

[sms]

Code: Select all

> [...] migrating an OpenVMS VM from VMWare Pro 17.5.2 to ESXi 8.02?

   I know practically nothing about ESXi (or why you'd prefer it to
VMWare), but...

> The disks weren't migrated properly, appeared as thinly provisioned and
> on the wrong controller (DKB rather than DKA)

   In my playing with VMware Fusion (Mac), I seem to recall (once?)
seeing multiple DK adapters.  (Might have been related to the VMDK kit.)
As I recall, I found some odd stuff in the disk specs in the .vmx file. 
Manually editing the .vmx file (removing the odd junk) solved that
problem.

   I have no idea what options might exist when importing an OVF disk to
(not "from") an ESXi VM.

   If I were able to create a working ESXi VM on the target server, but
I couldn't make the VMware-to-ESXi storage migration work, then I might
seek a way to use VMS BACKUP to save/restore the data.  Boot each VM
from a VMS installation DVD, and use BACKUP /IMAGE /SAVE_SET to save and
restore the data.  You might need to add a disk at each end to hold the
save set, and you might need to fool around with one or more schemes to
transfer the save set from one VM to the other, but some such method
would seem to stay within the bounds of known-working stuff.

[brianreiter]

So, it looks as if the Upload process adds and additional SCSI adapter which wasn't present in the original VM. Hence the ports changing from DKA to DKB.

I'm able to boot into the VMS installer, from there I can't see any disks even though the VM is configured to have 4.

Code: Select all

$$$ show dev d
show dev d

Device                  Device           Error   Volume          Free  Trans Mnt
 Name                   Status           Count    Label         Blocks Count Cnt
DMM0:                   Offline              0
DMM1:                   Mounted wrtlck       0 X86E923OE         97892    13   1

From the VMWare Pro install I see

Code: Select all

$$ show dev d

Device                  Device           Error   Volume          Free  Trans Mnt
 Name                   Status           Count    Label         Blocks Count Cnt
DMM0:                   Offline              0
DMM1:                   Mounted wrtlck       0 X86E923OE         97892    13   1
DKA0:                   Online               0
DKA100:                 Online               0
DKA200:                 Online               0
DKA300:                 Online               0

I'll have a tinker with the disks and see if there is a way to get them online.

I was hoping that the migration would be seamless (or as seamless as this kind of stuff ever is), as that should provide a better mechanism for deployment and backup, certainly inline with what customers may expect, especially if the customer is already invested in VM.

Added in 13 minutes 17 seconds:
So, after moving the disks to a SCSI controller, and deleting the SATA controller (to be on the safe side). I can now see the disks from the VMS installation boot.

Code: Select all

$$$ show dev d
show dev d

Device                  Device           Error   Volume          Free  Trans Mnt
 Name                   Status           Count    Label         Blocks Count Cnt
DMM0:                   Offline              0
DMM1:                   Mounted wrtlck       0 X86E923OE         97892    13   1
DKA0:                   Online               0
DKA100:                 Online               0
DKA200:                 Online               0
DKA300:                 Online               0
$$$ mount/over=id dka0
mount/over=id dka0
%MOUNT-I-MOUNTED, X86SYS mounted on _DKA0:
%MOUNT-I-REBUILD, volume was improperly dismounted; rebuild in progress
$$$ show dev d
show dev d

Device                  Device           Error   Volume          Free  Trans Mnt
 Name                   Status           Count    Label         Blocks Count Cnt
DMM0:                   Offline              0
DMM1:                   Mounted wrtlck       0 X86E923OE         97892    13   1
DKA0:                   Mounted alloc        0 X86SYS          2495552     1   1
DKA100:                 Online               0
DKA200:                 Online               0
DKA300:                 Online               0

Which is a start.

Added in 1 hour 35 minutes 34 seconds:
And success. It now boots.

So, repeated the Upload from VMWare to ESXi and now have a bootable VMS system after:

1) Adding a serial port (over TCP)
2) Moving all the disks to a supported SCSI adapter
3) Deleting the SATA controller

Still need to be manually booted but that should easily sorted.

[arne_v]

> [...] migrating an OpenVMS VM from VMWare Pro 17.5.2 to ESXi 8.02?

I know practically nothing about ESXi (or why you'd prefer it to
VMWare), but...

I believe it is like:

VMWare Player/Pro = type 2 hypervisor = great for dev and test

VMWare ESXi = type 1 hypervisor = great for prod

[brianreiter]

> [...] migrating an OpenVMS VM from VMWare Pro 17.5.2 to ESXi 8.02?

I know practically nothing about ESXi (or why you'd prefer it to
VMWare), but...

I believe it is like:

VMWare Player/Pro = type 2 hypervisor = great for dev and test

VMWare ESXi = type 1 hypervisor = great for prod

As Arne says, the plan is to develop/tinker/break on VMware Pro, and then deploy using ESXi.

Having an easy migration path is essential. So far I'm also seeing issues on the Windows VMs we are migrating.

Its a learning exercise, and all fun (in a way)