booting x86 -Oracle VM Virtual box Mgr- vmdk disks

[vmsxpert]

I am able to boot correctly x86 with vmdk disk provided by VSI . As soon as I connect to console and I give
"boot dka0" it starts booting correctly from that device .Also able to log into remotely with putty .

Issue 1 : Not able to get on to EFI Shell .What command should I give to get on to boot manager so that i can come to EFI shell ?
Generally in On-prem scenario if we type exit on console we can get into Boot Manager and from there to EFI shell .
But this is not working here .Please suggest some work around or am i doing something wrong .

Issue 2 :Able to login remotely successfully from putty session (both ways telnet & SSH ) to VM running x-86 but not able to ping host M/c from guest VM running x86 .
Also, I am able to do "$set h 0 " correctly on guest VM running Open VMS x86 .

VM (running Open VMS x86 ) has an IP address : 192.168.56.23
Hos M/c (win 11) : 192.168.56.1

Please advise .

Thanks
Sumit

[sms]

Code: Select all

> [...] (You'd probably want to add a default route (to your router),
> [...]

   DHCP could handle that without any help from you.  I don't use DHCP
with my VMS systems, so I need to deal with that manually.

[vmsxpert]

Hi Alex ,

Please see the private message .
Thanks a ton!!

Added in 3 hours 21 minutes 32 seconds:
Hi Alex ,

1. I have attached 2 files for laptop ipconfig details and VMS node ip config details .Please have a look.

2. I have a doubt for gateway IP Address: <> what should be given here ??

Not able to ping laptop from VMS node or vice-versa. Please help .

THanks & Regards
Sumit

[vmsxpert]

In addition to earlier mail , please also see these settings :

[vmsxpert]

HI Alex ,

I have done those settings (Bridged , DHCP) and got the DHCP working fine now . But still not able to ping Guest VM (where OPen VMS is installed ) from Host .Problem persists .

Host M/C IP":

1. DHCP logs :

Internet Systems Consortium DHCP Client 4.4.2

Copyright 2004-2020 Internet Systems Consortium.

All rights reserved.

For info, please visit https://www.isc.org/software/dhcp/


Listening on Socket 0.0.0.0/IE0

Sending on Raw/IE0

DHCPREQUEST for 10.0.2.15 on IE0 from 0.0.0.0 to 255.255.255.255 port 67, state: 1

DHCPNAK from 192.168.0.1

DHCPDISCOVER on IE0 to 255.255.255.255 port 67 interval 6

DHCPOFFER of 192.168.0.103 from 192.168.0.1

DHCPREQUEST for 192.168.0.103 on IE0 from 0.0.0.0 to 255.255.255.255 port 67, state: 4

DHCPACK of 192.168.0.103 from 192.168.0.1

bound to 192.168.0.103 -- renewal in 36937 seconds.

Listening on Socket 192.168.0.103/IE0


2. $ sh net

Product: DECNET Node: ABHI Address(es): 1.1
Product: TCP/IP Node: ABHI Address(es): 192.168.0.103
$


3. Show inter
Packets
Interface IP_Addr Network mask Receive Send MTU

IE0 192.168.0.103 255.255.255.0 1196 90 1500
LO0 127.0.0.1 255.0.0.0 70 70 4096
$

4. Show routes

$ tcpip sho routes

DYNAMIC

Type Destination Gateway

AN 0.0.0.0 192.168.0.1
AH 127.0.0.1 127.0.0.1
AN 192.168.0.0/24 192.168.0.103
AH 192.168.0.103 192.168.0.103
$

5.
$ tcpip sho routes/permanent

PERMANENT

Type Destination Gateway

PN 0.0.0.0 router
$

6.
$ tcpip sho hosts

LOCAL database

Host address Host name

10.0.2.15 ABHI
192.168.0.103 ABHI
127.0.0.1 LOCALHOST, localhost
192.168.0.1 router
$

Can we put some route so that VM starts pinging from Host .

THanks for responses .

[alexwong]

Your OpenVMS config looks fine but I can ping both ways on mine. What's the route table on the PC? Do a traceroute to VMS. Is there something on Win blocking pings eg. firewall, antivirus, etc?

route print
tracert 192.168.0.103

As I mentioned, all I did was set up dhcp on VMS and nothing on Win. I doubt its an OpenVMS problem, try with Linux as guest. BTW it's better to do generic postings to the forum rather than to a specific person as he/she may be away.

[sms]

Code: Select all

> $ tcpip sho hosts
> 
> LOCAL database
> 
> Host address Host name
> 
> 10.0.2.15 ABHI        <--- I wouldn't expect that to be helpful.
> [...]

... but, I also wouldn't expect it to affect "ping <ip_address>".


> Can we put some route so that VM starts pinging from Host .

   Every system on the 192.168.0.0/24 subnet should be able to
communicate to anyone else on that subnet without any extra effort. 
They should all have a route like:

AN    192.168.0.0/24                        192.168.0.103

and that should do the job.

   LAPTOP-IPCONFIG.txt contains many things about which I know nothing,
but it does show:

Wireless LAN adapter Wi-Fi:
[...]
   IPv4 Address. . . . . . . . . . . : 192.168.0.102(Preferred) [...]
   Subnet Mask . . . . . . . . . . . : 255.255.255.0

   All the virtual stuff I've ever done involved VMware Fusion (Mac)
with an Ethernet interface (wired) which is used exclusively by the VM
(different from the one used by macOS).  I've never tried using a
wireless interface for any of this stuff.

   From your laptop, what do these do?:

      ping 192.168.0.1
      ping 192.168.0.102
      ping 192.168.0.103

   Have you tried any test other than "ping"?


> [...] Is there something on Win blocking pings eg. firewall,
> antivirus, etc?

   By default, Windows Firewall prevents "ping" responses.  My Windows
system is currently complaining that the Microsoft Windows Operating
System has been blocked from accessing my graphics hardware, so I can't
investigate much at the moment[*], but a Web search for terms like:
      windows firewall ping
should find many suggestions.  I don't remember if you need to add a new
Inbound rule, or enable an existing (but disabled) Inbound rule, but I
believe that it's one of those.

   I don't know what effect (if any) Windows Firewall might have on any
virtual network interfaces.

[*] Problems like this are why I generally prefer to use a Mac.

[vmsxpert]

Output of "route print" on laptop:

C:\Windows\System32>route print
===========================================================================
Interface List
7...00 ff 20 d9 84 d6 ......ExpressVPN TAP Adapter
16...00 ff 85 20 e5 bd ......TAP-Windows Adapter V9
19...0a 00 27 00 00 13 ......VirtualBox Host-Only Ethernet Adapter
6...92 0f 0c b1 0e d3 ......Microsoft Wi-Fi Direct Virtual Adapter
14...96 0f 0c b1 0e d3 ......Microsoft Wi-Fi Direct Virtual Adapter #2
15...00 50 56 c0 00 01 ......VMware Virtual Ethernet Adapter for VMnet1
23...00 50 56 c0 00 08 ......VMware Virtual Ethernet Adapter for VMnet8
4...90 0f 0c b1 0e d3 ......Realtek RTL8822CE 802.11ac PCIe Adapter
1...........................Software Loopback Interface 1
===========================================================================

IPv4 Route Table
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 192.168.0.1 192.168.0.102 35
127.0.0.0 255.0.0.0 On-link 127.0.0.1 331
127.0.0.1 255.255.255.255 On-link 127.0.0.1 331
127.255.255.255 255.255.255.255 On-link 127.0.0.1 331
192.168.0.102 255.255.255.255 On-link 192.168.0.102 291
192.168.16.0 255.255.255.0 On-link 192.168.16.1 291
192.168.16.1 255.255.255.255 On-link 192.168.16.1 291
192.168.16.255 255.255.255.255 On-link 192.168.16.1 291
192.168.37.0 255.255.255.0 On-link 192.168.37.1 291
192.168.37.1 255.255.255.255 On-link 192.168.37.1 291
192.168.37.255 255.255.255.255 On-link 192.168.37.1 291
192.168.56.0 255.255.255.0 On-link 192.168.56.1 281
192.168.56.1 255.255.255.255 On-link 192.168.56.1 281
192.168.56.255 255.255.255.255 On-link 192.168.56.1 281
224.0.0.0 240.0.0.0 On-link 127.0.0.1 331
224.0.0.0 240.0.0.0 On-link 192.168.56.1 281
224.0.0.0 240.0.0.0 On-link 192.168.0.102 291
224.0.0.0 240.0.0.0 On-link 192.168.37.1 291
224.0.0.0 240.0.0.0 On-link 192.168.16.1 291
255.255.255.255 255.255.255.255 On-link 127.0.0.1 331
255.255.255.255 255.255.255.255 On-link 192.168.56.1 281
255.255.255.255 255.255.255.255 On-link 192.168.0.102 291
255.255.255.255 255.255.255.255 On-link 192.168.37.1 291
255.255.255.255 255.255.255.255 On-link 192.168.16.1 291
===========================================================================
Persistent Routes:
None

IPv6 Route Table
===========================================================================
Active Routes:
If Metric Network Destination Gateway
4 4131 ::/0 fe80::3e52:a1ff:fe27:c5e5
1 331 ::1/128 On-link
4 4131 2406:b400:71:cfcc::/64 On-link
4 291 2406:b400:71:cfcc:648f:350a:18fd:b44b/128
On-link
4 291 2406:b400:71:cfcc:6bab:ef48:90c3:3cf9/128
On-link
19 281 fe80::/64 On-link
4 291 fe80::/64 On-link
23 291 fe80::/64 On-link
15 291 fe80::/64 On-link
4 291 fe80::2d3:c044:594a:76de/128
On-link
15 291 fe80::444d:2f08:a9e4:1932/128
On-link
19 281 fe80::a203:953:96d6:9895/128
On-link
23 291 fe80::da42:485d:67d7:5930/128
On-link
1 331 ff00::/8 On-link
19 281 ff00::/8 On-link
4 291 ff00::/8 On-link
23 291 ff00::/8 On-link
15 291 ff00::/8 On-link
===========================================================================
Persistent Routes:
None

C:\Windows\System32>

===============================================================================
===================================================================================
output of tracert on laptop:
======================

C:\Windows\System32>tracert 192.168.0.103

Tracing route to 192.168.0.103 over a maximum of 30 hops

1 5 ms * 1 ms ARCHER_C5 [192.168.0.1]
2 * * * Request timed out.
3 * * * Request timed out.
4 * * * Request timed out.
5 *

NOTE : I am not able to see 192.168.0.103 (OPEN VMS , VM IP) in the routing table on laptop.

Please suggest.

[cct]

I think your home network is more complicated than we realise.

Bear in mind that VSI do not support WiFi networks.

You seem to have your PC as 192.168.1.102, with a gateway of 192.168.0.1
If VMS is getting its address through DNCP from 192.168.0.1, it should be getting a default route to 192.168.0.1, which if that gets a DHCP address from there, should be enough

However you have a host of other subnets, that would not , by default, be routable.

Perhaps you could give a network diagram - not just massive output from random commands

[sms]

Code: Select all

> iPv4 Route Table
> ===========================================================================
> Active Routes:
> Network Destination Netmask Gateway Interface Metric
> [...]
>  192.168.0.102 255.255.255.255 On-link 192.168.0.102 291
> [...]

   I don't like that netmask, "255.255.255.255" (/32).  Why isn't it
"255.255.255.0" (/24)?

> C:\Windows\System32>tracert 192.168.0.103
> 
> Tracing route to 192.168.0.103 over a maximum of 30 hops
> 
> 1 5 ms * 1 ms ARCHER_C5 [192.168.0.1]
> 2 * * * Request timed out.

   I believe that that's a result of your (bad?) netmask.  The Windows
laptop at 192.168.0.102 should be able to talk directly to the VMS
system at 192.168.0.103; it should not need to go through your router to
do that.  (Except that, I suppose, all wireless traffic must go through
the wireless part of your router.)

   Around here, for example, proa is a Mac at 10.0.0.87 (/24), and v87
is a VMware Fusion VMS system at 10.0.0.184 (/24, on a different Mac):

proa$ traceroute v87
traceroute to v87.antinode.info (10.0.0.184), 64 hops max, 52 byte packets
 1  v87 (10.0.0.184)  1.495 ms  0.611 ms  0.504 ms

Note that the message went directly to v87, _not_ to my router
(10.0.0.1).

   Even with a WiFi-connected Macbook, "mba" at 10.0.0.29 (/24), the
router is not (visibly) involved:

mba$ traceroute v87
traceroute to v87.antinode.info (10.0.0.184), 64 hops max, 52 byte packets
 1  v87 (10.0.0.184)  9.728 ms  1.846 ms  1.933 ms

   With a netmask of "255.255.255.255" (/32), your Windows laptop
believes that the only thing it can talk to from "192.168.0.102" (/32)
is 192.168.0.102".  Or, apparently, the gateway router (192.168.0.1).

   I can't think of any situation where a netmask of "255.255.255.255"
(/32) would make any sense.  My WiFi-connected, DHCP-using
Macbook uses the same "255.255.255.0" (/24) netmask as everyone else
here, so I see no reason to have that (crazy?) /32 netmask.

Added in 24 minutes 35 seconds:

Code: Select all

>  192.168.0.102 255.255.255.255 On-link 192.168.0.102 291

   Looking at this again, I may be misinterpreting that, but still,
other interfaces have a "myself" (my interface?) route like that, _plus_
a subnet route.  For example:

> 192.168.56.0 255.255.255.0 On-link 192.168.56.1 281
> 192.168.56.1 255.255.255.255 On-link 192.168.56.1 281

   But I see no such subnet route for 192.168.0.0/24.  I'd expect
something like:

      192.168.0.0   255.255.255.0   On-link 192.168.0.102 291
      192.168.0.102 255.255.255.255 On-link 192.168.0.102 291

but I see only the "myself" route:

>  192.168.0.102 255.255.255.255 On-link 192.168.0.102 291

   I've never seen anything like that, and I don't know how that could
happen.  But I claim that if that's the _only_ route in the table for
"192.168.0.x", then that would explain the strange behavior you're
seeing.

[alexwong]

Your route table is missing some 192.168.0.x entries as sms indicated. Tracert shows your default gateway responded, meaning the least-specific route was triggered. It should be using a more-specific route(192.168.0.0).

Even though wifi is unsupported according to VSI, my setup runs ok. But I have a bare-bone network with only wifi-enabled. My route entries are:

Network Destination Netmask Gateway Interface Metric
192.168.160.0 255.255.255.0 On-link 192.168.160.213 291
192.168.160.213 255.255.255.255 On-link 192.168.160.213 291
192.168.160.255 255.255.255.255 On-link 192.168.160.213 291

Tracing route to 192.168.160.91 over a maximum of 30 hops
1 <1 ms <1 ms <1 ms 192.168.160.91

192.168.160.213 = wifi nic
192.168.160.91 = OpenVMS

I suspect something(VMware?) is stepping on VB routes. Try disabling all network interfaces on your laptop except wifi. Big Bang approach: uninstall all network-related software(VMware,VB,ExpressVPN,etc) and reinstall VB only.

Note, show relevant snippets in the post. For info dumps, attach files. It's hard yakka wading thru pages of guff.