Блог о технологиях, технократии и методиках борьбы с граблями
Откровенно говоря, сколько я ни вожусь с хостингами, в качестве клиента, так и не могу понять, чем руководствуются люди, поднимающие хостинг на VMware и гордо повествующие клиентам о том, что это очень дорого и сложно.
По каким то причинам залип компьютер, при включенной виртуальной машине VMware, в которой крутилось довольно ресурсоемкое приложение. Причем завис компьютер настолько, что в итоге пришлось его перегрузить.
Странная тема- мне вроде бы казалось что я уже писал про автостарт виртуальных машин в VMware ESXi, найти смог только тему про Workstation. Видимо еще много тем, которые как мне кажется я рассматривал на страницах своего блога, а на деле нет.
Возникла необходимость закинуть файлец на виртуальную машину VMware с установленной Windows системой, но к сожалению загрузить винду получалось только в безопасном режиме. То есть сетка не работает, VMware Tools тоже, так что файл с хостовой системы на виртуалку обычным переносом не перекидывается, внешние устройства не подключаются. Спрашивается что делать?
Возникла необходимость высунуть машинку хостящуюся на виртуальной ферме VMware ESXi в дикий интернет, с ограничением доступа к локалке. Точнее возникла необходимость дать к ней доступ левым людям из вне с полными правами на рута. В связи с чем поднялся вопрос о том как пробросить одну из виртуальных машин в DMZ.
Надо отметить, что, порыв сообщества на тему атаки на хост ESXi, я не смог найти достаточно инфы об уязвимостях позволяющих получить доступ к ноде или соседям по ноде, поэтому собственно и решил, что оптимальным решением будет убрать хост в DMZ, предоставив к нему доступ из интернета и закрыв локалку. Другое дело что существуют различные варианты атаки на L2 OSI теоретически позволяющие ломануть DMZ на уровне VLAN’а, но это уже совсем другая история, не имеющая отношения к этой. Тем более что и современные средства организации VLAN’ов предоставляют богатый функционал защиты и минимизируют риски от подобных атак. Если кому то интересно покопать на тему атак на VLAN, то дам несколько ключевых букаф:
CAM flooding;
MAC flooding;
VLAN Cross-talk Attacks;
VLAN Hopping;
ARP spoofing;
Spanning-Tree attacks;
VRRP / HRSP tampering
До появления VMWare Workstation 8, организация автоматического подъема виртуальных машин вместе с хостовой системой, представляла собой пляску с бубнами вокруг пакета Windows 2003 Resource Kit и реестра. Но благодаря тому что в 8 версии VMWare Workstation появился такой функционал как Shared VMs, процедура организации автостарта виртуальных машин превратилась в простейший набор кликов мышкой.
Собственно функционал Shared VMs позволяет расшаривать виртуальные машины между всеми пользователями хоста, и как следствие поднимать их для всех автоматом, так что вошедшему в систему пользователю не придется перехватывать права на машину, а он просто подключается к уже запущенной виртуалке.
Настраивается автостарт виртуалок следующим образом:
Предположим что у нас уже есть созданные виртуальные машины, которые мы завели или подтянули в VMWare Workstation 8 и в этой связи они находятся в папке My Computer (левый фрейм окна VMWare Workstation 8, под названием Library ). Мы простым движением мыша перетягиваем их в папку Shared VMs, после чего система нам предлагает их скопировать или смувить, и вы выбираете то что вам не запрещает конфессия. После этого правым кликом мыши щелкаете по Shared VMs и выбираете Manage AutoStart VMs, где расставляете галки- каким виртуальным машинам стартовать при запуске хостовой операционки, и ниже выставляете паузу между запусками виртуальных машин, чтобы одновременным стартом не прогнуть хостовую машину.
Также в контекстном меню Shared VMs вы можете выбрать все великолепие разграничения прав управления виртуальными машинами, как в плане доступа к ним, так и в плане задач выполнения.
Попробовал тут под один свой проект поставить VMWare Server 2.0.2. Смысл проекта в том, что надо вести порядка 20 торговых терминалов Forex, для чего прогу надо запустить в 20 копиях. Хотели изначально повесить просто 20 штук терминалов, но потом подумали и решили это дело разграничить, так как терминалы могут глючить сами по себе, когда их пашет больше пяти штук на одной тачке. Да и уживаются они довольно спорно- на 2 гига влезают нормально только 3-4 штуки, а дальше начинаются глюки.
Так что арендовал сервак Windows 2008 под это дело с 24 гигами на борту, и поставил VMWare Server 2. Надо отметить что я пользовал все время Workstation, а тут решил стать честным парнем и воспользоваться бесплатной лицензией на Server, ибо его VMWare раздает бесплатно.
И тут то меня ждал облом, так как сама управлялка сервером работает через веб-интерфейс, так что обращаться к ней можно как с локальной машины, так и удаленно. Есессно что все крутится по ходу дела на джаве, так что для FF надо устанавливать дополнительный плагин. После его установки вроде стало очень удобно, так как для управления даже не было нужды лезть по RDP на сервер, но- оказалось что эта веб-морда дико глючит. Бродилка не входит в разделы, эпизодически не загружается сама управлялка инфраструктурой. Почему то лочится консольный экран системы, причем удаленно он матерится что не могу открыть, а локально просто не открывается. В итоге обычная свистопляска с попсовыми плюшками веб-интерфейса. Надо заметить, что я работал в первым сервером и у него интерфейс мало чем отличался от Workstation. А тут такой облом.
Так что в и тоге пришлось качать Workstation 8 с ставить все на неё, ибо сервак видимо стоит обождать до выхода третьей версии. Хотя идея конечно интересная.
В процессе ковыряния выяснился интересный момент, что когда веб-консоль сервера требует логин- ей надо скармливать системные аккаунты, например админа. Если админ залочен, то его можно оживить, путем ввода команды:
net user administrator /active:yes
