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

Я использую Open Nebula с 1 контроллером кластера и 3 узлами.

Я зарегистрировал узлы на внешнем контроллере, и я могу запустить виртуальную машину Ubuntu на одном из узлов.

Однако из моей сети я не могу пропинговать виртуальную машину. Я не совсем уверен, правильно ли я настроил виртуальную машину.

Узлы все имеют br0 интерфейсы, которые соединены с eth0, IP-адрес находится в диапазоне 192.168.1.x.

Файл шаблона, который я использовал для vmnet:

NAME = "VM LAN"
TYPE = RANGED

BRIDGE = br0 # Replace br0 with the bridge interface from the cluster nodes

NETWORK_ADDRESS = 192.168.1.128 # Replace with corresponding IP address
NETWORK_SIZE    = 126
NETMASK         = 255.255.255.0
GATEWAY         = 192.168.1.1
NS              = 192.168.1.1

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

Может быть полезно знать, что мы используем KVM в качестве гипервизора, и я не совсем уверен, может ли быть проблема с интерфейсом virbr0, который был автоматически создан при установке KVM.

Источник

2 ответа

Решение

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

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

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

Метод общего контекста

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

Если вы используете 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 для vm guest

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

Удачи

Источник

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

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

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

Источник
Другие вопросы по тегам