И еще вопрос вдогонку, при использовании VMware vCenter Converter Standalone что мешает в качестве Destination выбирать не ESX/ESXi, а VMware Workstation и, соответственно, выгружать сконвертированную машину сразу в сетевую папку?
в версии 4.1.0 (в или той что сейчас является последней) такого выбора я к сожалению не обнаружил из чего сделал вывод: что Vmware Converter теперь нет возможности выбрать destination
Ну оно понятно что ему там комфортнее, но админам ТВ3 удобнее в SCVMM ;)
Вопрос, сколько шансов если взять VHD, подключить каким угодно образом (хоть iSCSI) к машине источнику, dd..., и потом под Hyper-V запустить? Я понимаю что вопрос, мягко говоря, вакуумно-сферичен, но всё-таки?
Если VHD был от HVM, то шансы, я думаю, довольно большие (ведь Hyper-V тоже некое legacy hardware эмулирует?). Формат VHD XCP/XenServer цитрикс сделала совместимым с MS (за что её сильно ругали, ибо из-за этого добавились проблемы с снапшотами).
Чистый PV, c -xen ядром, понятное дело, запустить не получится. С pv_ops, вероятнее всего, получится (особенно, если это generic kernel с пачкой дров).
1) Умеет ли hyper-v с тупыми копиями работать? Я знаю, что xen через loop умеет. Вопрос: умеет ли винда работать с образами дисков, записанными в файл? Насколько я знаю, нет, не умеет.
2) Что будет делать линукс после запуска? Ну, зависит от того, как монитирование сделано. Если через метки uuid'ы, то ничего не заметит (возможно, нужно будет поправить сеть из-за persistent rules). Если через пути, то смена /dev/sda на /dev/hda может потребовать м… руками бутлоадер поправить.
Так что вопрос исключительно в функционале виндов.
Hyper-V как минимум, требует установки посторонней ОС со своими тараканами и концепциями. Майкрософт за столько лет до сих пор не соблаговолила написать клиента для RDP (да, потому мы с freerdp/rdesktop и мучаемся, включая глюки транслитерации и залипающий Альт), а по ssh администрировать винды неудобно, не смотря даже на наличие power shell.
Далее: xapi/xend позволяют использовать общую файловую систему. Я могу открыть легко файловую систему гостя из dom0. Как там у Hyper-V и её административной системы с поддержкой btrfs, xfs, raiserfs, ext4, zfs? Что-то мне подсказывает, что большую часть ой, не поддерживает. Я даже оставляю в стороне несовместимость атрибутов на ФС и кривую поддержку симлинков. Аналогично действует и в обратную сторону — MS так и не сподобилась написать модули для ntfs/exfat, так что если что, придётся пользоваться неизвестной стабильности модулями, основанными на реверс-инжиниринге.
Далее. Хост-система в Hyper-V не имеет штатно клиента для подключения к гостевым доменам по родным для него протоколам (где ssh от MS?).
Всё это приводит к простой вещи: из виндов управлять линуксовыми гостями неудобно, потому что майкрософт ленится реализовать interoperability. (Отвечая на вопрос: в обратном направлении усилия делаются, но всё упирается в невозможность, например, коммитнуть драйвер ext3 в ванильную ветку виндов).
Плюс Xen позволяет использовать паравиртуализацию, что иногда актуально. Можно ли мигрировать установленный на железо линукс (как минимум смена ядра) на паравирт — вопрос к тому же amarao.
Вам понадобится ядро нужного дистра, собранное с поддержкой работы в DomU (для убунты это linux-image-ec2. Его необходимо поставить и вытащить из файлухи с тем чтобы впоследстии скормить Xen. После чего надо просто сделать образы разделов и подрубить их к виртуалке. Если вдруг что-то не заведётся, вас выкинет в консоль initramfs, откуда можно невозбранно подмонтировать раздел и поправить fstab.
не совсем. xen уже давно поддерживает pv_ops ядра. Соответственно, generic ядро в котором pv_ops включено (насколько я знаю, оно включено в большинстве дистрибутивов) с зеном в pv будет работать, так же как в HVM, так же как на baremetall.
Ответьте на один вопрос: что удобнее:
а) поддерживать один гипервизор с его инструментами мониторинга, управления и автоматизации (hyper-V + scvmm), или
б) два гипервизора, один с полной интеграцией в существующую инфраструктуру (hyper-v + scvmm) и один полностью неподдерживаемый и не интегрируемый в существующеющую инфраструктуру?
Т.е. вы оправдываете такое решение только в безвыходной ситуации, когда компания уже плотно сидит на игле внедрённых решений от Microsoft?
Я правильно понимаю?
Более того, я его поддерживаю, т.к. если нет планов по использовании *nix виртуализации в организации, то во внедрении одного сервера только ради «православности» я не вижу смысла, в т.ч. финансового.
ЗЫ ESX сюда не подходит, т.к. SCVMM умеет работать с продуктами VMWare.
Я могу назвать как минимум одну важную плюшку зена по сравнению с hyper-v — это лицензирование. Во многих продуктах лицензирование по числу сокетов процессора. В зене можно все ядра объединять в единый сокет (то есть получается этакий монстр с одним процом и 16-32-48 и т.д. ядрами).
Блин, мне все говорят про эту фичу, но я так и не нашёл документации (поисками занимался года полтора назад). Как это делать-то? Киньте линком, пожалуйста.
Поскольку это функциональность не domain builder'а (чем различаются xapi и xend), а гипервизора (который и там и там один и тот же), то, наверное, можно. Более того, так как XenAPI одинаков (по-крайней мере за пределами концепции пулов), то вероятнее всего, в xend этот функционал тоже есть. Я xend знаю хуже xapi, так что точно сказать не могу.
Мокросовт, конечно, лошадка тёмная, но всё-таки общие подходы их работы прослеживаются чётко — совместимость, которую они однажды сделали, они обычно очень долго тянут даже когда она никому не нужна.
Кроме того, если они сделают такую подлянку, они заработают себе очень жирный минус в карму, а заодно разом потеряют все установки Hyper-V, в которых есть виртуализованный Linux.
Танки грязи Майкрософт кармы не боится. А совместимость могут поломать и с стороны линукса. Причём, если в случае обычного опенсорса это решается патчем на продукт, то в случае МС нужно, чтобы сначала кто-то из поддерживаемых вендоров это адаптировал, потом МС пошевелилась, и только после этого вышел бы KB/SP с поддержкой нужной фичи.
Ближайший пример — допустим, по какой-то причине нужно будет поломать pv_ops, на уровне ABI. Сколько времени пройдёт до появления патчей в KVM/Xen? Думаю, чуть меньше, чем понадобится VMWare, чтобы адаптироваться.
Сколько времени понадобится MS, чтобы обратить внимание на то, что в ванильном ядре какие-то изменения? Если в списке саппорта половина — RHEL-производные, которые до сих пор (в пятой версии) на 2.6.18, а о 2.6.34-36 ни сном ни духом?
Вообще, от подхода Microsoft к виртуализации я вижу реально ровно одно действительно существенное удобство (для себя).
А именно, если вы купили Windows 2008 и поставили его на железо, вы имеете право запустить ещё одну копию Windows 2008 в виртуалке. Мы звонили в MS, уточняли — имеется ли ввиду именно Hyper-V, или можем запускать в Xen? Нам ответили — не важно, в какой именно виртуалке; в любой можно.
Это уже преимущества лицензирования.
Windows Server 2008 R2 лицензируется одинаково для любой из виртуальных сред, однако Hyper-V идет в комплекте бесплатно и с большим количеством фич. Лицензия на Windows Server 2008 R2 Datacenter Edition лицензируется «на процессор» и позволяет запускать неограниченное количество экземпляров Windows Server в виртуальной среде.
миграция физических Linux серверов в виртуальную среду гипервизора Microsoft Hyper-V