Ваши сообщения об ошибках указывают на то, что dhclient не смог успешно работать. Вы также видели в своих журналах что-то вроде, dhcp4 (eth0): client pid XXXX exited with status 127? Или, если нет, есть ли другие записи журнала, связанные с dhcp4?

Предполагая, что вы получили ошибку exited with status 127, Я предложу решение. (Если у вас другая ошибка, дайте мне знать, и я отредактирую ответ.)

Поскольку у вас нет подключения к сети, вам необходимо войти в виртуальную машину через последовательную консоль, аутентифицировавшись паролем для учетной записи пользователя, имеющей доступ sudo для root.

Код выхода 127 означает, что программу не удалось запустить. Зачем? Что ж, попробуйте: запустите dhclient команду и посмотрим, что произойдет:

#> sudo dhclient --help
dhclient: error while loading shared libraries: libdns-export.so.1102: cannot open shared object file: No such file or directory

Хорошо, в этом случае dhclient не может загрузить необходимую библиотеку. Если вы выполните поиск в Google, вы можете найти эта старая ошибка Redhat что предполагает, что проблема решена путем повторного связывания библиотек с ldconfig:

#> sudo /sbin/ldconfig

После этого, dhclient успешно работает:

#> sudo dhclient --help
Internet Systems Consortium DHCP Client 4.2.5
Copyright 2004-2013 Internet Systems Consortium.
[…]

Затем перезапуск NetworkManager завершится успешно:

#> sudo systemctl restart NetworkManager.service

И сеть работает:

#> ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=52 time=1.98 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=52 time=0.258 ms

Причина сбоя сетевого стека при запуске экземпляра заключается в том, что загрузочный диск вашей виртуальной машины заполнен на 100%.

Решение состоит в том, чтобы увеличить размер диска.

Я написал эту статью, в которой подробно описаны необходимые шаги:

Изменить размер корневой файловой системы

Ниже временно исправлена ​​моя проблема;

(i) Войдите в свою виртуальную машину через последовательную консоль. Возможно, вам придется нажать кнопку возврата, чтобы появился логин.

(ii) Убедитесь, что память и дисковое пространство вашей виртуальной машины в порядке. Вы можете использовать такие инструменты, как `df -h для проверки вашего дискового пространства, если его недостаточно, вы можете следовать Джон Хэнли выше и увеличьте его. Когда все в порядке и единственная сеть дает сбой, переходите к шагу iii.

(iii) Отключить NetworkManager и настроить сеть вручную на centos можно следующим образом:

systemctl stop NetworkManager
systemctl disable NetworkManager
ifconfig eth0 <internal_ip> netmask 255.255.255.0
route add default gw <your-cloud-gateway>

После вышесказанного у вас будет полный доступ к вашей виртуальной машине Google, однако ваша виртуальная машина не будет видна другим виртуальным машинам, вам нужно будет настроить это с помощью команды маршрута, как показано ниже.

route add <other-VM-internal-IP> netmask 0.0.0.0 gw <you-cloud-gateway>

Вам нужно будет сделать это для каждой виртуальной машины, которую вы хотите видеть на своем виртуальном сервере.

Это временное исправление, так как вы можете потерять настройки при перезагрузке, в любом случае вы можете поместить эту команду в /etc/rc.local, чтобы они выполнялись при запуске.

Отказ от ответственности: я не очень опытен, но выше был мой способ исправить критически важный сервер, который только что пережил бедствие и нуждался в моих клиентах для быстрого восстановления обслуживания, поскольку я ищу постоянное решение.

Поскольку ваше состояние NetworkManager теперь ОТКЛЮЧЕНО, единственный способ подключиться к вашему экземпляру - это взаимодействие с последовательной консолью

Есть большая вероятность, что вы заранее не назначили локальный пароль для пользователя на экземпляре виртуальной машины и застряли здесь, но не беспокойтесь! вы также можете добавить следующую инструкцию, чтобы решить эту проблему:

Шаг первый, создайте сценарий запуска в облачной оболочке с помощью команды:

$ nano startup.sh и скопируйте в него следующее.

#! / bin / bash echo "пароль" | passwd --stdin имя пользователя

(где пароль - это желаемый пароль, должен быть заключен в кавычки. И имя пользователя - это желаемое имя пользователя) Нажмите ctrl + x, затем y, а затем введите, чтобы сохранить и выйти

Шаг второй: используйте следующую команду, чтобы вставить сценарий запуска в ваш экземпляр.

gcloud compute instance add-metadata example-instance
--metadata-from-file startup-script = путь / к / файлу

(где example instance - это имя вашего экземпляра, а путь к файлу - это место, где находится файл сценария запуска, в случае, если вы не изменили каталоги после создания файла, путь будет ./startup.sh

Шаг третий: вернитесь к экземплярам vm в консоли и перезапустите экземпляр. Как только он развернется, нажмите кнопку [Подключиться к последовательной консоли].

После завершения процесса запуска вы можете ввести свои учетные данные. Возможно, вам потребуется нажать клавишу ввода, чтобы получить приглашение на вход.

После входа в систему мы можем проверить место на вашем жестком диске, чтобы подтвердить записи журнала, используя команду:

df -h

Также вы можете использовать следующую команду в своем скрипте для удаления временного файла с целью очистки жесткого диска:

#! / bin / bash rm -rf / tmp / * rm -rf / var / tmp / * rm -rf / usr / tmp / * rm -rf / var / log / *