Мне нужно было переместить некоторые виртуальные машины из тестовой системы Virtualbox на рабочий хост KVM. Хосты - это две копии одной и той же аппаратной и программной системы (64-битный Ubuntu Server v16.04, если это важно).
Тут все не так уж и сложно, но сетевая часть.
Для гостей виртуального бокса у меня есть единственный адаптер virtio ethernet, подключенный к одному из устройств связи хоста. Гость легко доступен как из сети, к которой подключен хост, так и из самого хоста. Таким образом, гость похож на «просто еще один сервер в сети». Во время работы я ничего не вижу, кроме моста virbr0.
AFAIU, эту простую настройку нельзя воспроизвести под KVM. Если я использую мост, я не могу общаться от гостя к хосту. Предлагаемое решение - добавить второй интерфейс к гостю для такого использования.
Это единственный вариант, который у меня есть?
Затем, если доступны какие-либо технические подробности, я хотел бы знать, как Virtualbox может делать то, чего не может сделать KVM.
То, что вы описываете, - это абсолютно стандартная конфигурация моста KVM, документированная практически везде, куда вы хотите. Идея состоит в том, чтобы связать хост под мостом (мост должен содержать IP-конфигурацию хоста, а не связь), и виртуальная машина сможет использовать мост точно так же, как вы привыкли в vbox.
Когда у вас есть мост, доступный на хосте, virt-manager позволит вам выбрать совместно используемое сетевое устройство для подключения (например, новый мост), или вы можете просто обновить domxml для гостя, чтобы использовать мост, а не по умолчанию Сеть NAT
Я также потратил несколько дней на ответ, но все еще не совсем понял, поэтому не могу объяснить технические детали, но похоже, что способ, которым виртуальный бокс (мост хоста) не имеет хорошей производительности по сравнению с macvtap.
Доказательства:
http://www.math.cmu.edu/~gautam/sj/blog/20140303-kvm-macvtap.html
Это оказалось не так просто, как ожидалось. Общий намек @dyasny верен: это действительно выполнимо. Основные цели здесь:
Не используйте сторонние инструменты (например, virsh
,virtinst
или libvirt
), чтобы узнать и понять.
Запускайте виртуальные машины без root-прав с обычным администратором и непривилегированным пользователем.
Вот как я это сделал.
Отключите основной интерфейс хоста в /etc/network/interfaces
закомментировав строки для основного Ethernet.
Создайте сетевой мост, содержащий этот интерфейс в том же файле. Оригинальный интерфейс будет свободный IP, который пойдет на мост. Файл конфигурации будет выглядеть так:
auto eth0 # no iface and IP stuff
auto br0
iface br0 inet static
bridge_ports eth0
bridge_stp off
bridge_maxwait 0
bridge_fd 0
address 192.168.255.253/24
gateway 192.168.255.254
/etc/quemu/bridge.conf
, право собственности на root:kvm
конец разрешений 0640
. Каталог /etc/quemu/
должно быть root:kvm
и 0770
:
sudo mkdir -v /etc/qemu
# 'br0' is the same name as used in the previous step
echo allow br0 | sudo tee -a /etc/quemu/bridge.conf > /dev/null
sudo chown -R -vc root:kvm /etc/qemu
sudo chmod -vc 0770 /etc/qemu
sudo chmod -vc 0640 /etc/qemu/*
root
.
sudo chmod -vc u+s /usr/lib/qemu/qemu-bridge-helper
kvm
. Вам нужно будет выйти и войти в систему (или открыть новый сеанс), чтобы это стало возможным.
sudo usermod -a -G kvm `id -un`
sudo service networking restart
... \
-netdev bridge,id=net0,br=br0
где net0
- это пронумерованное сетевое устройство (в данном случае 1-е) и br0
- это имя интерфейса моста, как определено ранее. Так, например, полная командная строка может быть такой:
kvm -cpu host -machine q35 -boot order=dc -vga virtio -vnc 127.255.255.1:0 -name qemutest,process=qemutest -uuid 901f83ce-b999-459b-b1b6-a9ba94cac382 -smp cpus=4 -m size=8192 -cdrom /home/user/image.iso -drive file=/home/user/Desktop/QEMU/qemutest/qemutest-D0.qcow2,if=virtio -device virtio-net-pci,mac=02:19:3e:39:a5:de,netdev=net0 -netdev bridge,id=net0,br=br0
Вы можете использовать iptables, чтобы объединить внутренние IP-адреса гостей с вашими общедоступными, а затем использовать внутренние IP-адреса для подключения к гостям с хоста KVM.