Чтобы понять, как в конечном счете сделать кластер Беовульфа, я попробовал, после этого чтения, Создающего простой кластер Беовульфа с Ubuntu для соединения моего ПК с Выпуском Сервера Ubuntu 18.04.01 с моим ноутбуком, где я установил версию VMware того же Выпуска Сервера Ubuntu 18.04.01.
Это - содержание файла/etc/hosts в версии VMware Ubuntu 18.04.01 в ноутбуке:
127.0.0.1 localhost
127.0.1.1 ubuntu
# The following lines are desirable for IPv6 capable hosts
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
192.168.1.3 pc01
И это - содержание файла/etc/hosts Ubuntu 18.04.01 ПК:
127.0.0.1 localhost.localdomain localhost
::1 localhost6.localdomain6 localhost6
# The following lines are desirable for IPv6 capable hosts
::1 localhost ip6-localhost ip6-loopback
192.168.229.128 laptop
fe00::0 ip6-localnet
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts
192.168.1.3 pc01
172.17.0.1 pc01
172.18.0.1 pc01
172.20.0.1 pc01
172.19.0.1 pc01
172.21.0.1 pc01
Теперь... проверка с помощью ping-запросов от ноутбука Ubuntu до Ubuntu-ПК следует за 100%:
marco@ubuntu:~$ ping -c 3 pc01
PING pc01 (192.168.1.3) 56(84) bytes of data.
64 bytes from pc01 (192.168.1.3): icmp_seq=1 ttl=128 time=1.08 ms
64 bytes from pc01 (192.168.1.3): icmp_seq=2 ttl=128 time=2.42 ms
64 bytes from pc01 (192.168.1.3): icmp_seq=3 ttl=128 time=2.04 ms
--- pc01 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2017ms
rtt min/avg/max/mdev = 1.087/1.851/2.420/0.563 ms
marco@ubuntu:~$
В то время как проверка с помощью ping-запросов от Ubuntu-ПК к ноутбуку Ubuntu перестала работать полностью:
marco@pc01:~$ ping -c 3 laptop
PING laptop (192.168.229.128) 56(84) bytes of data.
--- laptop ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2040ms
Какова могла быть причина? Нетерпеливое ожидание Вашей любезной помощи. Marco
Обновления, как справедливо требуется: 1) sudo iptables-сохраняют в ноутбуке, дает "пустой" вывод:
marco@ubuntu:~$ sudo iptables-save
marco@ubuntu:~$
2) вывод IP в ноутбуке:
marco@ubuntu:~$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state
UP group default qlen 1000
link/ether 00:0c:29:b0:ad:7b brd ff:ff:ff:ff:ff:ff
inet 192.168.229.128/24 brd 192.168.229.255 scope global ens33
valid_lft forever preferred_lft forever
inet6 fe80::20c:29ff:feb0:ad7b/64 scope link
valid_lft forever preferred_lft forever
3): после включения первой опции "Bridged: Connected directly to the physical network, should I enable also the sub-option " Replicate physical network connection state"?
Три Важных Обновления: 1) Согласно этому документу онлайн: VMwareWorkstation9DocumentationCenter, который опция "Replicate physical network connection state" должна быть включена для разрешения IP-адресу, который будет возобновлен при перемещении от одной проводной или беспроводной сети до другого. Так, я сделал две пробных версии, включив эту опцию. Но что-то странное произошло: виртуальная машина, открытая успешно с моим именем пользователя и моим паролем. Но я не мог получить доступ к нему посредством обычного соединения SSH, потому что мой пароль не был распознан. После отключения опции "Bridged: Connected directly to the physical connection", при включении опции "NAT: used to share the host's IP address", мой пароль был распознан соединением SSH также...
2) Я обнаружил через ifconfig | grep inet, что, после включения опции "Bridged: Connected directly to the physical network" и подопции "Replicate physical network connection state", inet становится 127.0.0.1 Затем в/etc/hosts моего ПК, я обновил IP-адрес ноутбука к 127.0.0.1
marco@pc01:~$ ping -c 3 laptop
PING laptop (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=1 ttl=64
time=0.046 ms
64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=2 ttl=64
time=0.025 ms
64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=3 ttl=64
time=0.042 ms
--- laptop ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2053ms
rtt min/avg/max/mdev = 0.025/0.037/0.046/0.011 ms
Но тем не менее мой пароль не распознан при попытке получить доступ к VMware Виртуальный Machine'Ubuntu посредством соединения SSH...
3) Я попробовал также неспособное другая опция в Настройках VMware: VirtualMachineSettings02: "Только для хоста: частная сеть совместно использовала с хостом" С этой включенной опцией, как с опцией "NAT:Used to share the host's IP address", я могу соединиться с виртуальной машиной Ubuntu посредством соединения SSH, потому что в этом случае пароль распознан. Но, после обновления IP-адреса в/etc/hosts ПК ping к ноутбуку перестал работать полностью снова:
marco@pc01:~$ ping -c 3 laptop
PING laptop (192.168.30.128) 56(84) bytes of data.
--- laptop ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2055ms
Нетерпеливое ожидание Вашей любезной помощи. Marco
marco@ubuntu:~$ ping -c 3 pc01 PING pc01 (192.168.1.3) 56(84) bytes of data.
и
marco@pc01:~$ ping -c 3 laptop PING laptop (192.168.229.128) 56(84) bytes of data.
дает нам хорошую подсказку: эти две машины находятся в различных подсетях. Это было конкретно причиной, я попросил, чтобы Вы не отредактировали IP: они дают нам информацию.
Сетевая карта (NIC) на ноутбуке, вероятно, установлена на режим NAT в Ваших настройках VMware. Это означает, что VMware выполняет подмену всего трафика, происходящего с виртуальной машины на Ваши другие сетевые устройства.
Измените настройки в конфигурации виртуальной сети к режиму моста и удостоверьтесь, что ноутбук имеет IP в той же подсети (например, 192.168.1.x) как сервер, от которого Вы пытаетесь получить доступ к нему.
Это Вопросы и ответы по superuser.com дает немного больше информации о различных режимах NIC VMware Workstation.