У меня есть система с QEMU / KVM (через libvirt). Одна из его виртуальных машин должна присутствовать в подсети, которая не является локальной по отношению к хосту виртуальной машины. У меня есть система Linux в удаленной подсети. Есть ли способ настроить какой-то туннельный мост, чтобы виртуальная машина появлялась в удаленной системе? Это будет временная ситуация (надеюсь, до тех пор, пока владелец виртуальной машины не сможет настроить свою систему), и производительность сети и долговременная ремонтопригодность на самом деле не являются проблемой.
Чтобы дать более конкретную информацию:
Моя виртуальная машина имеет IP-адрес 192.168.54.155/24. Виртуальная машина имеет IP-адрес 192.168.65.71/24. У меня удаленная система 192.168.65.254/24. И хост виртуальной машины, и удаленная система работают под управлением Scientific Linux 6.5. Я не контролирую сеть или маршрутизацию между хостом виртуальной машины и удаленной системой. У меня нет доступа к гостевой ОС на виртуальной машине. Я хочу, чтобы трафик на IP-адрес виртуальной машины попадал на виртуальную машину, даже если ее хост не подключен напрямую к соответствующей сети.
Я пробовал использовать iproute2туннелирование, но Linux не позволяет мне добавить туннель к мосту. Я подумал об использовании какого-то iptables пытаясь направить трафик через туннель и заставить виртуальную машину думать, что она находится в правильной сети, но я не уверен, есть ли лучшие подходы. Как лучше всего выполнить этот взлом?
У вас есть пара вариантов, но оба они - заноза в заднице.
Чтобы немного помочь вам, вы ищете «туннель уровня 2» (знание того, что искать, - полдела!)
Вариант 1: используйте туннель «гретап». Это наивно поддерживается в большинстве современных дистрибутивов Linux.
Вариант 2: Установите openvswitch на хост и настройте туннели GRE между хостами. Вы, вероятно, можете настроить openvswitch для этого, но «более простой» способ - использовать контроллер OpenFlow (например, Ryu, который поставляется с простым модулем коммутатора), чтобы объединить их в один большой виртуальный коммутатор.
Я использовал вариант 2, но вариант 1 был бы более простым (хотя у меня он никогда не работал из-за других ограничений).