Re: lxc и public bridge
9 июня 2014 г., 22:29 пользователь Mikhail A Antonov <bart@solarnet.ru> написал:
> 09.06.2014 22:22, Dmitry A. Zhiglov пишет:
>> 9 июня 2014 г., 16:49 пользователь Mikhail A Antonov <bart@solarnet.ru> написал:
>>> 09.06.2014 16:40, Dmitry A. Zhiglov пишет:
>>>> 9 июня 2014 г., 15:42 пользователь Dmitry A. Zhiglov
>>>> <dmitry.zhiglov@gmail.com> написал:
>>>>> Остается уповать tcpdump?
>>>> Это какая-то беда в бридже, но черт побери не понятно какая.
>>>> tcdump показал, что от гостя наружу уходя arp запросы, но назад ничего
>>>> не возвращается => потому пинга нет
>>>> ebtables чистный. Изучаю
>>> А доходят они до получателя? Отвечает ли получатель? А если получатель
>>> пробует пинговать виртуалку?
>> Решено!
>>
>> Ответ неожиданный. Эта lxc-виртуалка работает под управлением hyper-v
>> 2012 и вот у него был выключен "МAC spoofing", со всеми вытекающими
>> проблемами.
>>
>> Спасибо за наводку и помощь.
> Виртуалка lxc внутри виртуалки hyper-v? А hyper-v случаем не внутри
> vmware запущен? :)
Не моё хозяйтсво. :) Но в принципе идея имеет право на существование.
lxc все же не чиствая виртуалка (так как она не использует VT-x), а
контейнер-окружение с "виртуализацией" (в кавычках) на уровне
операционной системы, и даже на одном ядре. Так что, по большому счету
тут одна честная виртуалка под hyper-v и lxc-контейнеры на ней.
Какой тут плюс.
Hyper-v не позволяет (а может уже позволяет) работать со всякими
вкусностями типа Hyper-V Dynamic Memory. Держать стопку виртуалок
оказывается накладно под hyper-v, а одну виртуалку с контейнерами
более гибко и дешевле.
Reply to: