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

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

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

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

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

Предполагая, что вы получили ошибку при выходе со статусом 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

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

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

(ii) Убедитесь, что память и дисковое пространство вашей виртуальной машины в порядке. Вы можете использовать такие инструменты, как `df -h, чтобы проверить ваше дисковое пространство, если его недостаточно, вы можете следовать руководству John Hanley выше и увеличить его. Когда все в порядке и единственная сеть выходит из строя, переходите к шагу 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 VM, однако ваша виртуальная машина не будет видна другим виртуальным машинам, вам нужно будет настроить это с помощью команды маршрута, как показано ниже

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

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

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

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

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

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

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

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

#! /бин/баш эхо "пароль" | passwd --stdin username

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

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

экземпляры вычислений gcloud add-metadata example-instance
--metadata-from-file startup-script=path/to/file

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

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

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

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

df -h

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

#! /бин/баш рм -рф /тмп/* rm -rf /var/tmp/* рм -рф /usr/tmp/* rm -rf /var/log/*