вторник, 8 апреля 2014 г.

Внимание: Уязвимость безопасности OpenSSL в программном обеспечении VMware

Огромная дыра в безопасности в библиотеке OpenSSL (ссылка), информация о которой в последние часы облетела многие новостные порталы (на русском), присутствует и в ряде продуктов VMware.

Угрозе подвержены VMware ESXi 5.5 и VMware ESXi 5.5 U1, содержащие библиотеки openssl-1.0.1b и openssl-1.0.1e.

Для проверки можно воспользоваться онлайн тестом (на свой страх и риск, мало-ли): http://filippo.io/Heartbleed/

Также для проверки можете запустить следующую команду из консоли ESXi:
echo -e "quit\n" | openssl s_client -connect <HOSTNAME>:443 -tlsextdebug 2>&1| [ "` grep -c 'TLS server extension \"heartbeat\" (id=15), len=1'`" -gt 0 ] && echo 'Vulnerable'

, где HOSTNAME - IP адрес или DNS имя ESXi.

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

Также в группе риска находятся следующие продукты, использующие OpenSSL 1.0.1 в том или ином варианте:
  • VMware vCenter Server 5.5 и выше.
  • VMware vCloud Automation Center 5.2 и выше.
  • VMware Horizon Workspace 1.0 и выше.
  • VMware Horizon Mirage 4.4.0 и выше.
  • и другие продукты.
На сайте VMware доступна статья по теме, включающая полный список продуктов, подверженных уязвимости.

    понедельник, 7 апреля 2014 г.

    Видео: VMware Horizon View Multimedia Redirection for Windows 7 Desktops

    Недавно обсуждал с коллегой преимущества использования VMware Horizon View Feature Pack и одной из функций данного пакета - Multimedia Redirection, позволяющей передавать видеопоток по сети с виртуальной машины и воспроизводить его средствами Windows Media Player, установленного на клиенте (этакий аналог DLNA).

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



    вторник, 1 апреля 2014 г.

    Немного истории: Norton Virtual Commander

    Не так давно мне посчастливилось отыскать дистрибутив одной крайне редкой программы для виртуализации настольных компьютеров - Norton Virtual Commander.

    Долгое время считалось, что основоположником технологии виртуализации на платформе Intel x86 была компании VMware, выпустившая в 1999 году VMware Workstation.

    Однако лишь немногим известно, что за 3 года до этого компания Symantec выпустила первую в мире программу-гипервизор - Norton Virtual Commander.

    Разработка Norton Virtual Commander началась еще в конце 80-х годов самим Питером Нортеном под платформу ZX Spectrum, однако отсутствие нормального ПЗУ в виде жесткого диска сильно осложняло работу операторов виртуальных ЦОД, каждая ВМ хранилась на отдельной компакт-кассете, которые приходилось постоянно переставлять, перематывать... Позже NVC был портирован под MS-DOS.

    По сегодняшним меркам возможности гипервизора были крайне примитивны:
    • Поддержка одновременной работы до 10-и виртуальных машин в режиме вытесняющей многозадачности.
    • Организация доступа к сети для виртуальных машин с помощью vDial-Up или vHub. При необходимости администратор мог поднять отдельную BBS ноду, куда ВМ могли дозваниваться по вечерам и обмениваться данными.
    • Возможность создания мгновенных снимков (снапшотов) ВМ путем распечатки дампа памяти на матричном принтере.
    • Включение аппаратного режима Turbo при наличии соответствующей кнопки на корпусе системного блока для повышения производительности.
    • Четыре настраиваемые заставки-скринсейвера.
    NVC устанавливался поверх ОС MS-DOS версии 6.x и требовал наличие оконного менеджера Norton Commander. Все управление осуществлялось через псевдографическую консоль и командную строку максимально приближенную к оригинальным продуктам для упрощения адаптации администраторов.




    Ноу-хау того времени - возможность организации отказоустойчивого кластера путем соединения пары рабочих станций с помощью нуль-модемных кабелей. Используя специальные внешние COM-хабы, можно было объединить в один кластер до 8-и компьютеров.

    Для работы NVC требовался IBM/PC совместимый компьютер оснащенный процессором Intel 80486 или Intel Pentium, 8 Мегабайтами ОЗУ, 3.5" floppy-дисководом для загрузки ПО гипервизора, CGA/VGA совместимым монитором, модемом US Robotics Courier 33.6k или коаксиальным Ethernet адаптером 10 Мбит/с.

    Среди поддерживаемых операционных систем были MS-DOS вплоть до версии 6.2, Red Hat Linux 1.0, 2.0 и 3.0, Novell NetWare 3.0, 4.x, IBM OS/2, а также набирающие тогда популярность Windows 95 и Windows NT 4.0. По словам некоторых энтузиастов, на NVC удавалось запускать даже Sun Solaris под PowerPC и старые советские карманные игры серии Электроника ИМ в режиме бинарной трансляции, однако производительность работы в таком режиме была крайне удручающей.

    В комплекте с NVC поставлялось дополнительное ПО: дефрагментатор памяти Lines, средство проверки доступности Prince of Persia и бенчмарк для тестирования производительности компьютера Wolfenstein 3D.

    Выйдя на заре эпохи Windows 95, Norton Virtual Commander быстро оказался забыт. Виной тому непонимание тогдашними системными администраторами всех преимуществ технологии виртуализации, которая казалась слишком сложной и требовательной к вычислительным ресурсам компьютера. Рынку ИТ потребовалось долгих и томительных три года, прежде чем другой апологет идеи виртуализации - компания VMware пошла тем же путем, снискав заслуженную славу и популярность, и став синонимом слова виртуализация. И кто знает, что бы случилось, если бы детище Symantec тогда "выстрелило" - сейчас все могло бы быть совсем иначе...

    понедельник, 31 марта 2014 г.

    Пара нюансов планирования и настройки VMware VSAN

    При подборе оборудования для организации VMware Virtual SAN следует руководствоваться списком совместимости (HCL). Данный список содержит перечень оборудования, протестированного и поддерживаемого для работы в VSAN. На текущий момент список не слишком обширен, так, например, отсутствуют как класс жесткие диски с интерфейсом SATA (в пользу более дорогих NL-SAS), но, все-таки, есть из чего выбрать.

    При выборе модели сервера, типа и количества накопителей, следует помнить, что в одном сервере может быть от 1 до 5-и дисковых групп, каждая из которых может содержать от 1 до 7-и жестких дисков и обязательно 1 SSD накопитель (с интерфейсом SATA, SAS или PCI-E). Согласно рекомендациям VMware, суммарная емкость SSD накопителей должна составлять 10% от полезной дисковой емкости (без учета места, отводимого под копии ВМ). Например, если в кластере VSAN будут размещены ВМ суммарной емкостью 10 ТБ, то необходимый объем SSD накопителей составит 1 ТБ, независимо от того, сколько реплик будут иметь эти ВМ (только одну, две, три или четыре).

    В серверы жесткие диски и SSD накопители могут подключаться как через SAS HBA адаптеры, так и через RAID-контроллеры.

    Для RAID контроллеров в зависимости от модели может быть доступен один из двух режимов презентации дисков: Pass-Through и RAID 0. Первый режим, который также часто называют JBOD, эквивалентен подключению диска напрямую или через HBA контроллер - гипервизор должен увидеть его без проблем.

    В RAID 0 режиме для каждого диска и SSD накопителя требуется создать отдельный логический том средствами RAID контроллера. Недостатком данного режима является то, что контроллер не передает гипервизору информацию SSD дисках, без чего невозможно сделать кластер VSAN.

    Исправляется эта проблема также, как и в случае с SSD накопителями для Virtual Flash Read Cache - вручную задать настройки для каждого тома:
    esxcli storage nmp satp rule add --satp <SATP_TYPE> --device <DEVICE_ID> --option "enable_ssd enable_local"

    Например вот так:
    esxcli storage nmp satp rule add --satp VMW_SATP_LOCAL --device mpx.vmhba2:C0:T0:L0 --option="enable_ssd"
    esxcli storage core claimrule load
    esxcli storage core claiming reclaim -d mpx.vmhba2:C0:T0:L0
    esxcli storage core claimrule run

    После этого SSD накопитель станет доступен для выбора.

    Посмотреть DEVICE_ID и SATP плагин можно с помощью команды:
    esxli storage nmp device list

    Подробнее в KB2013188.

    Еще одним неочевидным моментом (для тех, кто не читает официальную документацию) является требование по количеству хостов для кластера VSAN. Минимальное количество хостов - 3, позволит обеспечить Fault to Tolerate=1, т.е. хранить две копии одной ВМ на разных хостах и обеспечить ее доступность в случае отказа одного из них. Однако, для Fault to Tolerate=2, способного пережить отказ двух серверов с копиями ВМ, потребуется уже пятиузловой кластер, для FTT=3 - семиузловой. Общая формула: (N*2+1), где N - кол-во хостов, которые могут отказать.

    вторник, 25 марта 2014 г.

    Логин в FC фабрику без перезагрузки хоста в ESXi 5.5

    В некоторых случаях при добавлении в FC фабрику СХД и презентации томов для серверов ESXi, новые тома не появлялись в списке доступных без перезагрузки хоста.

    В версии ESXi 5.1 и ранее данная проблема решалась вводом одной из команд:
    echo "scsi-qlalip" > /proc/scsi/qla2xxx/adapter_id для HBA адаптеров QLogic.
    echo "dev_login wwpn" > /proc/scsi/lpfc/host_num для HBA адаптеров Emulex.

    Подробнее в KB1031199.

    Но начиная с версии ESXi 5.5, при использовании нативных драйверов устройств старые команды не работают. Вместо этого предлагается использовать универсальную команду:
    esxcli storage san fc reset -A vmhbaX

    Данную команду лучше всего выполнить для всех адаптеров, которым презентован том.

    Посмотреть список доступных HBA FC адаптеров можно с помощью команды:
    esxcli storage san fc list

    или из vSphere Client клиента Configuration | Storage Adapters.

    После этого следует выполнить повторное сканирование устройств из vSphere Client или с помощью команды:
    esxcli storage core adapter rescan --all

    и если все настроено правильно, тома должны будут появиться без перезагрузки.

    среда, 12 марта 2014 г.

    Тривиальное решение тривиальной проблемы с VMware Persona Management

    Вот как иногда бывает. Делаешь какую-то простую вещь, а она не работает из-за элементарной ошибки в настройках.

    Взять, например, VMware Persona Management, который позволяет создавать и синхронизировать перемещаемые профили пользователей.

    Вот, казалось бы - как можно пропустить такую очевидную вещь при настройке папки для хранения профилей?

    Отсутствие Full Control в настройках общей папки с профилями запрещает менять разрешения и владельца на объектах внутри папки. Из-за этого профиль пользователя не может нормально синхронизироваться, и при входе в систему пользователь может получить вместо своего профиля что-то вроде этого:

    и кучу ошибок в журнале событий Persona Management: "%Programdata%\VMware\VDM\logs\VMWVvp.txt".

    Резюме: одна галочка может спасти вам пару часов и тысячи нервных клеток.

    четверг, 6 марта 2014 г.

    Создание консистентных VSS снимков внутри ВМ под Hyper-V

    Не так давно мне пришлось решать задачу копирования базы с производственного MS SQL сервера, работающего внутри виртуальной машины под Hyper-V 3.0. Задача осложнялась тем, что на время копирования сервер нельзя было останавливать, прямого доступа по сети к ВМ не было, и, к тому же, в ВМ не было никакой системы резервного копирования кроме встроенной... и места для копии не было... и задачу надо было решить быстро.

    На выручку пришли известные многим мгновенные снимки (VSS Snapshots). Данный механизм позволяет создавать консистентные копии файлов и данные приложений, таких как: базы Microsoft Active Directory, Exchange или SQL Server, виртуальные машины Hyper-V и прочее.

    Краткая суть метода

    1) Создать VSS снимок раздела, на котором хранятся базы, внутри гостевой ОС.
    2) Создать снимок раздела, на котором хранятся виртуальные диски ВМ, на хосте Hyper-V.
    3) Смонтировать снимок с виртуальными дисками.
    4) Смонтировать виртуальный диск.
    5) Смонтировать снимок раздела на виртуальном диске.
    6) Скопировать нужные файлы баз с хоста Hyper-V.
    7) Размонтировать все в обратном порядке.
    8) ???
    9) Profit!

    Более подробно

    Для начала подключитесь к гостевой ОС и проверьте, что в системе присутствует и нормально работает VSS Writer для SQL сервера (SQLServerWriter). В консоли CMD выполните команду:
    vssadmin list writers

    Создайте VSS снимок, используя команду: vssadmin create shadow /for=X:
    , где X: - буква раздела, где размещаются искомые базы SQL сервера.

    Запомните, а лучше запишите значение параметра Shadow Copy ID и время создания, они потребуются в дальнейшем, чтобы найти нужный снимок.

    Теперь подключитесь к хосту Hyper-V, на котором работает виртуальная машина и проверьте, что на нем также присутствует необходимый VSS Writers для ВМ (Microsoft Hyper-V VSS Writer).

    Создайте VSS снимок, используя команду: vssadmin create shadow /for=X:
    , где X: - буква раздела, где размещаются vhd диски виртуальной машины.

    Смонтируйте мгновенный снимок, создав на него символическую ссылку с помощью команды mklink: mklink /D C:\VMSnapshots\ \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy3\
    , где C:\VMSnapshots\ - путь для монтирования (папки с таким именем быть не должно);
    \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy3\ - имя VSS снимка.

    Обратите внимание, что после имени снимка требуется поставить обратный слэш ("\"), в противном случае созданная ссылка будет работать некорректно.

    Откройте оснастку управления дисками (Disk Management - diskmgmt.msc) и в меню выберите Action | Attach VHD.

    В окне Attach Virtual Hard Disk укажите путь к виртуальному диску из смонтированного VSS снимка и поставьте флаг Read-only.

    Всем разделам на смонтированном диске будут автоматически присвоены буквы. Вы можете открыть нужный раздел, чтобы увидеть содержимое файловой системы гостевой ОС в момент снятия снимка. Однако, существует вероятность, что файлы базы данных будут неконсистентны. Для этого нам и потребуется первый снимок.

    В консоли выполните команду vssadmin list shadows чтобы проверить, что доступен VSS снимок, сделанный в гостевой ОС.

    Используя команду mklink, подключите VSS снимок, используя новые значения пути и имени снимка (например, "C:\SQLSnapshot"). Если снимков много, то найти нужный можно по значению параметра Shadow Copy ID и времени создания.
    mklink /D C:\SQLSnapshots\ \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy4\

    Теперь вы можете просто зайти в нужную папку по символической ссылке и скопировать нужные файлы базы с хоста Hyper-V.

    После копирования выполните следующие операции, чтобы привести систему в исходное состояние:
    1) Удалите символическую ссылку с VSS снимком гостевой ОС.
    2) Отмонтируйте vhd виртуальный диск (Detach) из оснастки Disk Management.
    3) Удалите символическую ссылку с VSS снимком виртуальной машины.
    4) Выполните команды vssadmin delete shadows /for=X: чтобы удалить лишние VSS снимки с хоста и из гостевой ОС.

    И как всегда несколько засад...

    По какой-то причине, виртуальные диски в формате vhdx не монтируются из read-only раздела.

    Иногда происходит конфликт автоматического назначения букв для разделов виртуального диска. В этом случае можно попробовать смонтировать виртуальный диск без флага Read-Only, вручную выставить нужную букву раздела, затем снова смонтировать виртуальный диск с флагом Read-Only.

    Альтернативный, в чем-то даже более простой, метод, заменяющий шаги 2-4, заключается в создании снимка ВМ целиком (Checkpoint / VM Snapshot) из консоли Hyper-V Manager с последующим монтированием исходного vhd диска ВМ в read-only. Пожалуй, единственным недостатком тут может быть только то, что при активной записи данных на диск, удаление снимка ВМ займет больше времени, чем VSS снимка.

    P.S. Надеюсь, кому-нибудь такой метод пригодится. При желании, если диски ВМ расположены на каком-нибудь общем томе, подключенном по iSCSI или FC, после создания снимков можно презентовать том в режиме read-only стороннему серверу, получив, таким образом, импровизированную Off-Host/LAN-Free систему резервного копирования. С ручным копированием через системного администратора. ;-)