Комментарии 57
Сколько проблем. В www.proxmox.com/ можно то же самое сделать за 5 минут, просто выбрал тип виртуализации и нужный дистрибутив.
Вы сравниваете холодное с мягким в данном случае, технологию виртуализации с ПО управления виртуальной инфраструктурой. Можно все необходимые действия автоматизировать при помощи тех же 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 или что там управляет кластером умеет переносить виртуальные машины на другие физ. узлы автоматом если к примеру от системы мониторинга пришел сигнал о неминуемой аварии аппаратного обеспечения на текущем узле. Или к примеру если нагрузка на компоненты текущего узла превысила заданый предел?

В обще есть ли аналог SCVMM PRO?
не знаю, не сталкивался с данной задачей. Обратитесь к разработчикам Proxmox, думаю они смогут объяснить как это сделать.
Ой, в таком ключе если дискутировать, можно вообще быстро запутаться.
Hyper-V — аналог OpenVZ/KVM, технология виртуализации;
Live Migration — аналог не знаю чего, но это уже компонент кластерной технологии;
Proxmox это как я понял SCVMM в нашей MS-вселенной;
Ну а PRO — это вообще надстройка над мониторингом, уверен что в *nix тоже есть пакеты которые мониторят что надо и могут отдавать команды кластеру в случае войны.
То есть тут минимум 4 более-менее отдельных аспекта и сравнить это все в комплексе достаточно объективно будет сложно по-моему.
Мне вот как раз и интересно насколько сложно сделать аналог связки Hyper-V+SCOM+SCVMM+SCDPM

Скорее всего что то подобное должно быть и для OpenVZ и KVM.
Я думаю всё есть, и построить примерно так же по сложности — концептуально технологии не должны сильно отличаться. Просто недостаточное знание «другой стороны силы» порождает отношение «как у вас все криво и сложно выглядит, вот у нааааас...» — а по сути все то же самое наверное, просто другая идеология и методы работы с продуктами.
Hyper-V это аналог XEN, даже не аналог а перепиленная его инкарнация.
OpenVZ это сильно отличающаяся технология виртуализации, имеющая некоторые ограничения (ядро едино для ноды и гостей) но очень сильно сокращающая накладные расходы.
KVM это аналог VirtualPC.
Вот это разрыв шаблона. :)

Предоставьте пожалуста факты о том что Hyper-V это одна из версий XEN.

А я то думал что это развитие технологий которые Virtual PC и Virtual Server которые Microsoft давным давно приобрела у компании Connectix.
Ну факты не факты, но резонные подозрения есть —
«Картинка архитектуры 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, XEN и VMWare очень похожа. Разница лишь в том монолитный ли это гипервизор или микроядерный.

en.wikipedia.org/wiki/Hypervisor
virtualizationreview.com/blogs/everyday-virtualization/2009/06/type-1-and-type-2-hypervisors-explained.aspx
www.scribd.com/doc/30063295/Hyper-Visor-Type-Comparison

Как я уже писал 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
Паравиртуализация
Hyper-V тоже работает с некоторым оборудованием методом эмуляции. Например с сетевой картой Legacy и IDE дисками.

При этом ничто не мешает ему работать про технологии паравиртуализации.

Я ведь не сказал что Hyper-V прямой потомок Virtual Server. Я лишь утверждаю что многое из Virtual Server перекочевало в Hyper-V. :)
А на основании чего вы утверждаете:
«Я лишь утверждаю что многое из Virtual Server перекочевало в Hyper-V. :)»

Вы участвовали в разработке этого продукта, или исходники смотрели?

И хочется услышать больше конкретики — что общего у Hyper-V и Virtual Server кроме фирмы производителя, назначения и того что один продукт пришел на смену другому?
Я таки работаю в MS, имею доступ к внутренним источникам и вижу что происходит с продуктами на ранних стадиях. :)

Как я уже писал общее например то как они работают с эмулируемыми устройствами.
Ну тогда тем более хочется услышать от вас больше технических подробностей, может даже в виде отдельной статьи.

А мне, за не имением доступа к подобным сведениям, остаётся поверить вам на слово.
Как закончу с описыванием запуска всех распространенных Linux/Unix под Hyper-V, наверно возьмусь за статью об эволюции наших продуктов виртуализации.
Вы правы только в том что 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 предоставляет полностью независимое окружение, со своим (произвольным) дистрибутивом на выбор, набором ПО и системных библиотек.
Которыми администратор контейнера может распоряжаться полностью по своему усмотрению (обновлять, устанавливать, удалять).
Так же нет никакой возможности узнать что происходит за пределами контейнера.
Все ограничения связаны только с ядром, всё остальное как в реальной системе.
Спасибо вам за разъяснение, немного не так представлял, теперь ясно.
В общем OpenVZ очень похоже на Solaris Containers (Zones). Или на Virtuozo Windows Containers.
Да,
Причем Virtuozo Windows Containers и OpenVZ являются продуктами компании Parallels.

Правда признаюсь, что наличие решения под MS Windows я упустил из виду.
Не ради холивара, а из интереса: оно в сравнении с Xen как по производительности получается?
К сожалению сравнений производительности с результатами которых согласились бы все стороны я не видел.

Мне кажется что Hyper-V лучше подходит для компаний в которых есть специалисты по Windows за счет интеграции с продуктами Microsoft и легкости в освоении для людей привычных к Windows.
Такой заголовок специально сделан для поисковиков. Это позволяет быстрее помочь людям которые ищут сведений по данной теме.
Для поискового робота тег Title выставляемый в начале страницы из названия топика имеет гораздо больший вес чем абстрактные надписи на странице которые мы считаем тегами записи.

Посему писать название топика с оглядкой на поисковики выгоднее чем усердствовать с доморощеными тегами если конечно хочешь помочь людям быстро найти твою статью.
Ну за игры с поисковым рейтингом и фармингом можно и бан получить. Да и смысла особого нет т.к денег я на этом все равно не зарабатываю. :)
Недавно читал, что обмен данными между виртуалками на Hyper-V проходит не «внутри машины», а используя коммутатор, к которому подключена хост-машина. Якобы пакеты не могут роутиться внутри машины, и попадают на коммутатор, а потом опять в виртуалку. Сказано было, что это специфика Windows. Это правда? ;)
Это отчасти правда, только тут надо понимать что имеется ввиду виртуальный коммутатор, а не та физическая циска, к которой ваш сервер подключен. При установке роли Hyper-V ваш физический адаптер превращается волшебным образом в виртуальный коммутатор с единственным протоколом собственно самой этой коммутации. А в хосте появляется новый адаптер (по сути виртуальный), который подключен к этому самому виртуальному коммутатору (по сути физический адаптер — точка выхода во внешний мир из хоста). Далее все виртуальные адаптеры виртуальных машин общаются уже через этот виртуальный коммутатор.
Как видите, тут просто несколько сложная терминология. Так что ответ — правда, через коммутатор. Но он у вас внутри сервера и если общение только между хостом и его гостями — никуда пакеты дальше не побегут.
Все зависит от того как вы подключили виртуальные машины друг к другу. Весь обмен идет через виртуальные коммутаторы. Их три типа:

External — связь с внешними системами через реалную сетевую карту
Internal — виртуальный коммутатор в ОЗУ для обмена данными между хостовой ОС и гостевыми машинами
Private — виртуальный коммутатор в ОЗУ для обмена данными только между гостевыми машинами

Подробнее написано тут itband.ru/2009/04/%D0%B2%D0%B8%D1%80%D1%82%D1%83%D0%B0%D0%BB%D1%8C%D0%BD%D1%8B%D0%B5-%D0%BC%D0%B0%D1%88%D0%B8%D0%BD%D1%8B-%D0%B8-%D1%81%D0%B5%D1%82%D0%B8/
Интересно было бы глянуть, как CentOS чувствует себя, если дать ему 2ТБ ОЗУ.

Мне тоже интересно глянуть, как в Hyper-V можно дать виртуалке больше 64Гб. :-)
В новых прототипах Hyper-V гостевой можно дать гораздо больше ОЗУ чем в текущей версии и процессоров больше 4-х.

Коллега Кибкало в своем блоге публиковал скриншоты. :)

Самое главное не забыть про то, что после обновления ядра надо не сразу перезагружаться, а сначала собрать модули под новое ядро, иначе ребута не произойдёт скорее всего :) Т.е. всё вывалится в kernel panic.
Инструкция по таким манипуляциям — тут. Мне уже пришлось ею воспользоваться :)
Скоро и эта проблема уйдет в прошлое. В ядрах выше 2.6.32 уже встроены компоненты Hyper-V их не нужно ставить отдельно.

А пока что можно чинить вот так
www.devplace.nl/.../updating-hyper-v-drivers-after-kernel-upgrade-on-centos

Уже сейчас SLES 11 SP1 и Ubuntu 10.10 работают под Hyper-V с синтетическими устройствами на стандартном ядре сразу после установки. Обновления ядер им не страшны.
Ссылка поломалась, а хотелось бы глянуть, может есть проще способ, чем я нашёл.
А ubuntu надо потестить — как раз хотел себе поднять такую виртуалку.
А, глянул, тоже самое, что я делал :) Проще никак. С другой стороны, и так всё просто :)
В сети натыкался на инструкцию с применением ksplice для обновления ядра CentOS. К сожалению ссылку потерял.
Драйвер мыши пока в подвешеном статусе он вроде GPL но не ясно когда его в ядро добавят.
чтобы время не «убегало» в гостевой CentOS в /boot/grub/grub.conf добавляю divider=10 notsc в строку kernel
Рекомендуумый официально способ синхронизации времени гостевой Linux системы — установка пакета adjtimex.

Забыл об этом написать. :(
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.