Вы сравниваете холодное с мягким в данном случае, технологию виртуализации с ПО управления виртуальной инфраструктурой. Можно все необходимые действия автоматизировать при помощи тех же SCVMM+VMMSelfServicePortal. Да и никто не мешает сохранить проделанную работу (с уже интегрированными компонентами) как готовый шаблон и потом использовать его для новых машин.
это все конечно понятно, но проще же вставить диск в привод, поставить proxmox, тыкнуть три раза и получить в том же OpenVZ контейнере CentOS или FreeBSD в KVM без траты времени :)
Эмммм… Запускаем SCVMM -> New VM from Template «CentOS with integrated components» -> Next -> Next -> идем курить пока образ из библиотеки деплоится. Разве много времени потрачено? Поймите, Андрей писал о том как подружить CentOS с Hyper-V, которая вообще говоря официально not supported. И не забываем еще что Hyper-V впринципе Microsoft-oriented. Поэтому у меня встречный вопрос — а proxmox на стадии развертывания машины с Windows сможет в ней автоматом без вмешательства задать пароль админа, вбить серийник, применить всю кастомизацию, и включить в домен, так чтобы когда я докурю — мог под своей доменной учетной записью заходить и работать?
Думаю да, если в Windows не отстает от современных инсталляторов вроде Anaconda или хотя бы поддерживает как FreeBSD install.cfg. Тут я вам точно не могу сказать, т.к. у нас нет возможности использовать Windows в highload.
Проделать процедуру надо один раз а потом просто клонировать машину при необходимости.
К сожалению с Proxmox работать не доводилось. Он умеет делать Live migration — переносить виртуальную систему без прерывания обслуживания и разрыва TCP соединений между физическими серверами?
А proxmox или что там управляет кластером умеет переносить виртуальные машины на другие физ. узлы автоматом если к примеру от системы мониторинга пришел сигнал о неминуемой аварии аппаратного обеспечения на текущем узле. Или к примеру если нагрузка на компоненты текущего узла превысила заданый предел?
Ой, в таком ключе если дискутировать, можно вообще быстро запутаться.
Hyper-V — аналог OpenVZ/KVM, технология виртуализации;
Live Migration — аналог не знаю чего, но это уже компонент кластерной технологии;
Proxmox это как я понял SCVMM в нашей MS-вселенной;
Ну а PRO — это вообще надстройка над мониторингом, уверен что в *nix тоже есть пакеты которые мониторят что надо и могут отдавать команды кластеру в случае войны.
То есть тут минимум 4 более-менее отдельных аспекта и сравнить это все в комплексе достаточно объективно будет сложно по-моему.
Я думаю всё есть, и построить примерно так же по сложности — концептуально технологии не должны сильно отличаться. Просто недостаточное знание «другой стороны силы» порождает отношение «как у вас все криво и сложно выглядит, вот у нааааас...» — а по сути все то же самое наверное, просто другая идеология и методы работы с продуктами.
Hyper-V это аналог XEN, даже не аналог а перепиленная его инкарнация.
OpenVZ это сильно отличающаяся технология виртуализации, имеющая некоторые ограничения (ядро едино для ноды и гостей) но очень сильно сокращающая накладные расходы.
KVM это аналог VirtualPC.
Ну факты не факты, но резонные подозрения есть —
«Картинка архитектуры Hyper-V очень похожа на картинку архитектуры Xen. Говорят, что они, собственно, взяли все части Xen, которые позволила лицензия, а остальные переписали. Прозвучала также фраза „Linux с поддержкой Hyper-V“ — это, собственно, Linux over Xen, то есть ядро, обученное тому, что снизу у него лежит не железо, а гипервизор Xen. То есть гипервизор Hyper-V отдаёт вверх такой же интерфейс, как и Xen. Наводит на мысли.» k001.livejournal.com/676361.html
P.S. автор сего поста работает в Parallels над OpenVZ
Как я уже писал Hyper-V это новая инкарнация Virtual Server. Технологии виртуализации из которых потом вырос Hyper-V были в 2003 году приобретены Microsoft в процессе поглощения компании Connectix. При этом стоит отметить что линейка продуктов виртуализации Connectix на тот момент была весьма продвинутой.
Превая бета версия XEN появилась в конце 2003 года. Это был даже не продукт а пока еще рабочий прототип.
Linux с поддержкой Hyper-V это стандартное ядро версии выше чем 2.6.32. В него просто добавлены компоненты драйверов отданные Microsoft сообществу под лицензией GPL.
Стоит отметить что этот код драйверов разрабатывался вместе с компанией Xenosource которую впоследствии приобрел Citrix.
Поэтому и неудивительно что интерфейс драйверов подходит и к Hyper-V и к XEN. Их изначально делали совместимыми с обеими системами. Microsoft объединилась со своим давним партнером Citrix дабы конкурировать с VMWare было проще.
Еще одно доказательство этого тот самый проект Citrix Satori о котором я писал в статье.
Так что рассказы про Hyper-V который XEN не состоятельны. :)
Я нигде не нашел информации о том что Virtual Server является технологией паравиртуализации, зато есть инфорация о том, какое железо эмулирует Virtual Server, что говорит об обратном.
Так что Hyper-V и Virtual Server не могут быть родственными технологиями.
знакомимся с Virtual Server 2005
Паравиртуализация
А на основании чего вы утверждаете:
«Я лишь утверждаю что многое из Virtual Server перекочевало в Hyper-V. :)»
Вы участвовали в разработке этого продукта, или исходники смотрели?
И хочется услышать больше конкретики — что общего у Hyper-V и Virtual Server кроме фирмы производителя, назначения и того что один продукт пришел на смену другому?
Вы правы только в том что Hyper-V является родственником XEN, потому как они — паравиртуализация.
OpenVZ как я понял — это технология изоляции пользовательских пространств над ядром. Получается что скажем тот же Windows мы на нем не запустим? Опыта общения с ней не было, если неправильно понял — поправьте меня.
А KVM вроде как технология полной виртуализации вообще, какой же это тогда VirtualPC, который без основной ОС жить не хочет?
Про Hyper-V ответил чуть выше.
А OpenVZ по сути это продвинутый chroot/jail повышающий удобство безопастность и контроль над ресурсами, да эта технология доступна только под Linux, да гостями могут быть только Linux машины и на гостях не удастся загружать дополнительные модули ядра. Но накладные расходы на такую виртуализацию составляют всего порядка 3%, что во многих случаях является очень важным аргументом.
Да и OpenVZ не запрещает использовать параллельно тот же KVM на той же железной ноде, для виртуализации того что не взлетит под OpenVZ.
Ну в таком случае аналог OpenVZ у Microsoft складывается из нескольких технологий — это Terminal Services плюс разделение контекстов выполнения для приложений, например SQL Server instances или те же Application Pools у служб IIS. То есть добиться того же эффекта можно, но комбинируя по кускам. И тут я согласен что в OpenVZ это видимо удобнее реализовано.
Нет, ничего общего.
OpenVZ предоставляет полностью независимое окружение, со своим (произвольным) дистрибутивом на выбор, набором ПО и системных библиотек.
Которыми администратор контейнера может распоряжаться полностью по своему усмотрению (обновлять, устанавливать, удалять).
Так же нет никакой возможности узнать что происходит за пределами контейнера.
Все ограничения связаны только с ядром, всё остальное как в реальной системе.
К сожалению сравнений производительности с результатами которых согласились бы все стороны я не видел.
Мне кажется что Hyper-V лучше подходит для компаний в которых есть специалисты по Windows за счет интеграции с продуктами Microsoft и легкости в освоении для людей привычных к Windows.
Для поискового робота тег Title выставляемый в начале страницы из названия топика имеет гораздо больший вес чем абстрактные надписи на странице которые мы считаем тегами записи.
Посему писать название топика с оглядкой на поисковики выгоднее чем усердствовать с доморощеными тегами если конечно хочешь помочь людям быстро найти твою статью.
Недавно читал, что обмен данными между виртуалками на Hyper-V проходит не «внутри машины», а используя коммутатор, к которому подключена хост-машина. Якобы пакеты не могут роутиться внутри машины, и попадают на коммутатор, а потом опять в виртуалку. Сказано было, что это специфика Windows. Это правда? ;)
Это отчасти правда, только тут надо понимать что имеется ввиду виртуальный коммутатор, а не та физическая циска, к которой ваш сервер подключен. При установке роли Hyper-V ваш физический адаптер превращается волшебным образом в виртуальный коммутатор с единственным протоколом собственно самой этой коммутации. А в хосте появляется новый адаптер (по сути виртуальный), который подключен к этому самому виртуальному коммутатору (по сути физический адаптер — точка выхода во внешний мир из хоста). Далее все виртуальные адаптеры виртуальных машин общаются уже через этот виртуальный коммутатор.
Как видите, тут просто несколько сложная терминология. Так что ответ — правда, через коммутатор. Но он у вас внутри сервера и если общение только между хостом и его гостями — никуда пакеты дальше не побегут.
Все зависит от того как вы подключили виртуальные машины друг к другу. Весь обмен идет через виртуальные коммутаторы. Их три типа:
External — связь с внешними системами через реалную сетевую карту
Internal — виртуальный коммутатор в ОЗУ для обмена данными между хостовой ОС и гостевыми машинами
Private — виртуальный коммутатор в ОЗУ для обмена данными только между гостевыми машинами
Самое главное не забыть про то, что после обновления ядра надо не сразу перезагружаться, а сначала собрать модули под новое ядро, иначе ребута не произойдёт скорее всего :) Т.е. всё вывалится в kernel panic.
Инструкция по таким манипуляциям — тут. Мне уже пришлось ею воспользоваться :)
Уже сейчас SLES 11 SP1 и Ubuntu 10.10 работают под Hyper-V с синтетическими устройствами на стандартном ядре сразу после установки. Обновления ядер им не страшны.
Установка и настройка CentOS Linux 5.5 под Hyper-V