9 июня 2014 г., 22:29 пользователь Mikhail A Antonov <[email protected]> написал: > 09.06.2014 22:22, Dmitry A. Zhiglov пишет: >> 9 июня 2014 г., 16:49 пользователь Mikhail A Antonov <[email protected]> >> написал: >>> 09.06.2014 16:40, Dmitry A. Zhiglov пишет: >>>> 9 июня 2014 г., 15:42 пользователь Dmitry A. Zhiglov >>>> <[email protected]> написал: >>>>> Остается уповать 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, а одну виртуалку с контейнерами более гибко и дешевле.
