Домашняя виртуализация. Citrix XenServer vs VMware vSphere ESXi. Часть 2 – 4. Citrix Xenserver. Баги.

xenserver-logo

Как и в любом другом программном продукте в XenServer есть баги. Однако обидно когда сталкиваешься с критичными багами уже в первые часы настройки виртуальной машины.

В процессе настройки и установки обновлений я столкнулся с двумя багами, из-за которых я отказался от использования XenServer.

Баг 1. Черный экран и курсор мыши при загрузке. Долгая загрузка.
После установки XenServer я сразу же накатил через XenCenter сервис-пак SP1 и все обновления, которые появились после него. После этого я установил в качестве виртуальной машины Windows 7. Она встала успешно и я несколько раз перезагрузился, чтобы удостовериться в этом. После этого я решил установить xs-tools, которые необходимы в том числе для увеличения быстродействия виртуальной машины. После перезагрузки я обнаружил странное – виртуальная машина в консоли XenCenter около 5 минут висела с черным экраном и я лишь мог пошевелить курсором мыши – единственным что было видно. После этого система отвисала, загружался рабочий стол и можно было работать в штатном режиме.
После долгих экспериментов я выснил, что виной тому новая версия xs-tools. Выяснил я это следующим образом. Установил XenServer 6.5 без накатывания сервис-пака и каких-либо обновлений. Утсановил Windows 7, затем xs-tools. После перезагрузки Windows 7 заработала штатно и никаких тормозов не было. Затем я установил SP1, и обновил xs-tools до версии, которая в него входит. После перезагрузки я опять получил черный экран.
Знаете, это как-то досадно обновить однажды xs-tools и получить зависающую при загрузке систему. Допустим я даже захочу проверять xs-tools на тестовой ВМ перед обновлением основной ВМ, но мне все равно непонятно как можно было пропустить такой досадный баг при тестировании. Так что в данном случае мой совет такой:
Не обновлять xs-tools, если всё и так работает. Работает – не трогай.
Скрепя сердце с этим багом еще можно мириться, но я нашел баг похлеще.

Баг 2. Ошибка при пробросе USB-устройства. Unknown device.
Для работы с виртуальной машиной, мне необходимо пробрасывать в нее различные usb-устройства. Для проброса usb-клавиатуры я воспользовался стандартной командой:

xe vm-param-set other-config:pci=0/0000:00:1d.0 uuid=xxx

Но после загрузки системы меня ждал неприятный сюрприз: клавиатура хоть и оказалась проброшенной, но при этом была совершенно нерабочей. В диспетчере устройств она именовалась как “Unknown device”, драйвера не устанавливались, и клавиатура соответственно не работала.
Причиной тому установка апдейта XS65ESP1004.
Проверил я это так. Установил Xenserver, установил Windows 7. После этого начал устанавливать все обновления по одному, начиная с сервис-пака XS65ESP1, проверяя после установки и перезагрузки XenServer работоспособность Windows 7. Итог удручающ. После установки обновления XS65ESP1003 с клавиатурой все еще номрально, она подгружается и нормально работает в виртуальной машине, а вот после установки XS65ESP1004 она уже превращается в “Unknown device”.
Итоговый совет такой:
Не устанавливать обновление XS65ESP1004 и любые другие обновления которые его в себя включают, например XS65ESP1008.
Проблема в том, что это фактически значит совсем не обновлять XenServer. Для меня это не вариант, потому что я хочу использовать и Windows 10, поддержка которой добавилась лишь в последнем обновлении.
Открытие этого бага для меня вбило последний гвоздь в крышку гроба XenServer. Как то совсем не клево после очередного обновления обнаружить, что функционал одной из систем нарушен, откатываться, и больше никогда не обновляться, забыв про новые версии операционок и про исправление текущих багов.

На этом я закончил исследование XenServer лишь прогнав бенчмарки на Windows 7 со стоковой версией xs-tools.

В следующей статье мы сравним производительность XenServer и ESXi.

Leave a Reply

Your email address will not be published. Required fields are marked *