On Fri, Apr 16 2010, Вереск wrote: > kvm -drive file=/home/veresk/fuse/Windows.qcow,if=virtio,boot=on -net > nic,model=virtio -net vde,sock/tmp/myswitch -m 1024 > Unknown network device: vde > В данном случае ядро самосборное, 2.6.32
Судя по диагностике, этого не умеет именно kvm. Так что этот путь лучше оставить в покое, если не хотите обновляться или бэкпортить. > >> # launch vde switch >> vde_switch -F -sock /tmp/myswitch >> # launch QEMU instance >> qemu linux.img -net nic -net vde,sock=/tmp/myswitch >> >> > И как это должно выглядеть со стороны хоста и клиента? Кажется, > постижимый для меня уровень абстракций уже пройден :-) Наверное, это не важно (если обновляться не будете). -net nic создаёт "сетевую карту" в VM, а параллельное ему -net vde (как и все остальные фиговины вроде -net tap) "втыкает" эту "карту" в "свитч". Список -net nic'ов сопоставляется поэлементно списку -net всегоОстального (но это вы читали, наверное). >> Если хочется обойтись, тогда либо бридж, как в начале говорили, либо >> vpn-клиент внутри VM, как советуют в соседнем треде (да, я перечитал >> первое сообщение, всё соответствует. Клиент openvpn под винду есть). >> > То есть надо поднять просто сеть через br0 и прицепиться уже из гостя > к внешнему IP хозяина? Некрасиво получается: фактически внутренний > трафик VPN'a Гость-Хост начинает бегать через внешнюю сеть. А ведь в > дальнейшем это будет некоторый белый IP. Кажется, тут кроется какая-то > проблема. Это да, что некрасиво то некрасиво, поэтому в общем-то я и не предложил подобного (нужный уровень отчаяния ещё не достигнут). >> Ещё по итогам перечитывания - обнаружил, что вы не поднимаете br0 >> (ifconfig должен показывать все задействованные интерфейсы без -a; > О! Ценное замечание, надо будет опробовать, может что-то и добьюсь. Уточню: любой интерфейс, который не UP, работать не должен. Т.е. какое бы решение не выбрали, проверяйте, что все задействованные интерфейсы подняты, даже если адреса на них нет. -- Regards, Anton Kovalenko +7(916)345-34-02 | Elektrostal' MO, Russia
