Подключение виртуальной сети к реальной локальной сети в кластере OpenNebula

Когда вы впервые приступаете к настройке OpenNebula, консоль на основе VNC становится вашим помощником. я настоятельно рекомендую настройте это, прежде чем пытаться диагностировать что-либо еще, потому что очень полезно иметь возможность смотреть на состояние вашей виртуальной машины, даже если ее сетевая конфигурация нарушена. Серьезно - не проходите, не собирайте 200 долларов - попробуйте запустить компонент noVNC, а затем вернитесь к другой работе по настройке OpenNebula.

Что касается вашего фактического вопроса - проблема почти наверняка в том, что вы используете стандартный образ ОС без каких-либо сценариев контекстуализации сети. OpenNebula по своей задумке фактически не управляет IP-адресами, хотя поддерживает их пул и «сдает в аренду». На самом деле он назначает MAC-адрес виртуальному интерфейсу Ethernet, который имеет желаемый IP-адрес, закодированный в последних 4 байтах MAC-адреса, и операционная система должна распознать это и назначить IP-адрес соответствующим образом.

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

Я столкнулся с той же проблемой, и это была виртуальная машина, которую я установил с помощью ubuntu vmbuilder.

Проверить это вступление, которое включает полный vm. Я уверен, что это должно сработать для вас.

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

Общий метод контекста

Таким образом, оказывается, что установка файлов контекстуализации в виртуальную машину - довольно простая задача.

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

Создайте файл копии (hostfile to guestfile, убедитесь, что он разделен одним пробелом?)

copy.cfg

<path>/rc.context /etc/init.d/vmcontext
<path>/postinstall.sh /tmp/postinstall.sh

Создайте хук после установки

postinstall.sh

#!/bin/bash
# create mount point for context image
mkdir /mnt/context
# setup vmcontext at runlevel 2 service level 1
ln -s /etc/init.d/vmcontext /etc/rc2.d/S01vmcontext

Создать скрипт для chmod для гостевой виртуальной машины

chvm.sh

#!/bin/bash
# vmbuilder passes vmguest root as $1
chroot $1 /tmp/postinstall.sh

Наконец, отредактируйте файл конфигурации vmbuilder для виртуальной машины.

yourvm.cfg

...
copy = <full_path>/copy.cfg
execscript = <full_path>/chvm.sh
...

Затем создайте с помощью vmbuilder

sudo vmbuilder kvm ubuntu -c vmbuilder.cfg

Добавляем vnc на основе туманности

Включите что-то подобное в свой контекст

GRAPHICS = [
  LISTEN = 0.0.0.0,
  PORT   = 5900,
  TYPE   = vnc ]

Затем туннель ssh к компьютеру, который находится в сети гостевых машин

ssh -L 5900:127.0.0.1:5900 yourserver.com

И откройте клиент vnc по адресу 127.0.0.1 на локальном компьютере.

Мысли

Nebula не может заставить kvm / libvirt запускать ваши диски на hd * / sh *, поэтому вам нужно поиграть с тем, где они заканчиваются (и отредактируйте rc-файл, чтобы отразить это). Например. с моей настройкой Ubuntu изображение qcow2 получает / dev / sda, а изображение контекста получает / dev / sr0.

У меня также была проблема, из-за которой kvm или nebula не могли угадать формат моего изображения .qcow2. Следовательно, в DISK мне пришлось включить DRIVER = qcow2. Эта же проблема возникает для архитектуры процессора, поэтому в ОС мне пришлось включить ARCH = x86_64 (поскольку я работал с гостевой системой amd64).

Удачи