В инфраструктуре из нескольких серверов задача миграции виртуальных машин между гипервизорами если и возникает, то редко и разово. А вот если счет серверов идет на десятки, то вероятность параллельного использования двух гипервизоров весьма высока - кто-то это делает для экономии на лицензиях, кто-то чтобы не класть все яйца в одну корзину. И миграция виртуальных машин между Hyper-V и VMware может оказаться непростой задачей.
Уже некоторое время существует решение для ускоренной миграции из VMware в Hyper-V, разработанное с участием NetApp - MAT4Shift. Основная сложность в миграции - необходимость конвертировать диск с данными, а это требует существенных затрат времени (и ресурсов СХД). Если использовать только MAT (Microsoft Automation Toolkit), миграция 1ТБ диска может занять несколько часов. MAT4Shift за счет использования технологии FlexClone в СХД (да-да, конечно требуется не только утилита, но и СХД NetApp FAS) позволяет радикально сократить время миграции. Скорость возрастает, так как фактически не происходит конвертации данных, изменяются только заголовки и метаданные, после этого VMDK “превращается” в VHDX диск. Утилита также удаляет vmware tools и вносит необходимые изменения в настройки сетевых интерфейсов и VLAN. Время миграции виртуальной машины из VMware в Hyper-V сокращается от нескольких часов до всего нескольких минут.
Несмотря на достигнутые результаты, хочется еще, как минимум, конвертировать VM и из Hyper-V в VMware. Чтобы закрыть вопрос миграции в гетерогенной виртуальной среде, NetApp выпустил отдельный продукт - NetApp OnCommand Shift. Именно благодаря ему можно без лишних затрат времени и при минимальном участии администраторов производить миграции VM из VMware в Hyper-V и наоборот.
Как же осуществляется миграция?
ПО собирает данные о настройках виртуальной машины, которые необходимо будет воспроизвести после миграции.
Создается клон виртуальной машины (технология FlexClone в СХД NetApp FAS). Независимо от размера диска VM, процесс клонирования происходит практически мгновенно.
Происходит автоматизированное удаление утилит (VMware tools или Hyper-V Integration tools).
Дальше некоторое время требуется для настоящей магии - замены метаданных и заголовков в снимке диска (VMDK/VHDX). Сами данные не изменяются, а так как объем метаданных сравнительно небольшой, время конвертации диска мало зависит от размера исходных данных.
Если необходимо, устанавливается новый набор утилит.
Переносятся настройки, сохраненные на первом этапе. После миграции будут сохранены все сетевые настройки, подключения к VLAN и названия сетевых подключений.
Если нужно перенести не одну, а сразу несколько VM, автоматизировать процесс поможет модуль OnCommand Shift PowerShell.
Еще одним преимуществом OnCommand Shift является то, что у нас нет необходимости в двукратном увеличении дискового пространства - данные в новом формате занимают те же самые блоки, что и данные до миграции. Это может быть достаточно важно при планировании массовых миграций.
Поддерживаемые гипервизоры: VMware ESXi 5.0 и выше, Microsoft Windows Server 2008R2 Hyper-V и выше. На NetApp должна быть установлена Clustered Data ONTAP 8.2 и выше, также потребуется создать виртуальную машину (требования самые скромные), в которой и будет выполняться OnCommand Shift.
Да, все это бесплатно, но работает только для владельцев СХД NetApp - остальным придется либо тратить на миграцию больше времени, либо искать альтернативы (про которые я, впрочем, пока не слышал).
Контейнеры уже наделали много шума за последний год — в свое время даже про виртуализацию говорили меньше. Популярность их, безусловно, не случайна — многие решения можно построить на основе микро-сервисов. Многие разработчики поддерживают такой подход (и именно от них идет столько шума про контейнеры). Той изоляции, которую предоставляет виртуализация уже недостаточно — слишком много накладных расходов, чтобы изолировать каждый сервис, контейнеры обеспечивают гораздо большую эффективность в плане затрат ресурсов.
Многие наверное еще осенью слышали обещание Microsoft о грядущей поддержке Docker в новой версии Windows. И вот, пришла пора узнать подробности — вчера в Microsoft было сразу два анонса, имеющих непосредственное отношение к контейнерам.
Во-первых, это контейнеры Hyper-V. Благодаря интеграции с Docker, код, работающий в рамках одного контейнера, изолирован от процессов в операционной системы и процессов в других контейнеров. Hyper-V контейнеры можно будет развертывать как обычный Windows Server контейнер, так и в виде виртуальной машины Hyper-V — довольно интересная опция, которая может стать аргументом для принятия технологии корпоративным сектором. Управление обоими видами контейнеров осуществляется через Docker.
Во-вторых, объявлено о еще одной редакции Windows Server. Это минифицированная операционная система с говорящим за себя названием Nano Server. В результате масштабного рефакторинга существенно сокращен размер ядра, а сама система поддерживает удаленную установку и управление. Nano Server оптимизирован для облачных вычислений и DevOps разработки. Наконец-то нам обещают меньше патчей и апдейтов, а также быструю перезагрузку. Редакция Nano Server будет доступна уже в следующем релизе Windows Server, поэтому ждать остается не так уж и долго.
Пользователь сможет устанавливать только те компоненты, которые действительно нужны. Результат от таких оптимизаций весьма многообещающий — на текущий момент декларируется:
уменьшение размера VHD-файла на 93%
потребуется на 92% меньше патчей — (возможно речь идет о потенциальном количестве, за счет сокращения числа устанавливаемых сервисов)
снижение числа перезагрузок на 80%
Чтобы все это достичь пришлось избавиться от GUI, отказаться от поддержки 32 битных приложений, MSI и от целого ряда других, стандартных для Server Core, компонентов. В том числе, нет поддержи локальной авторизации и RDP — все управление осуществляется только удаленно через PowerShell и WMI. Для обеспечения удобства управления нас ждут изменения в PowerShell — будут поддерживаться, например, передача файлов и удаленная отладка. Кроме того, планируется представить новые web-утилиты как замену локальных инструментов управления.
Так как Nano Server это именно переработанная версия Windows Server, то полная совместимость с API (в рамках оставшихся в Nano Server компонентов) упростит разработку нового ПО. Visual Studio будет полностью поддерживаться, так что экосистема не должна оказаться пустой.
Например, в Chef плотно занимаются интеграцией с Nano Server, заявляя о том, что новая платформа (Nano Server плюс автоматизация от Chef) станет отличным решением для разработки в стиле DevOps.
Само собой, Nano Server будет и отличной базой для развертывания на нем контейнеров Windows Server и Hyper-V контейнеров. В мире Linux аналог уже доступен — Red Hat Enterprise Linux Atomic Host.
Уже в конце апреля, на конференции Build 2015, можно будет увидеть контейнеры Windows «живьем».
Вот, теперь можно и начать разворачивать виртуальные машины!
В 15 минут конечно не уложились и попутно настроили десяток серверов, но зато "бесплатный" гипервизор и вся инфраструктура на базе Microsoft. Это конечно все сарказм и шутки - документ на самом деле интересный и полезный. Стоит прочитать или хотя бы помнить, что он существует.
Если VMware предлагает EVO:RAIL с тем, чтобы пользователи могли сами развернуть всю инфраструктуру максимально быстро при минимальных знаниях, то Microsoft, по всей видимости, дает возможность партнерам заработать на сервисе и продавать заказчикам услуги по развертыванию. Это конечно имеет смысл, но вот вопрос что выберет партнер - развернуть за 15 минут VMware и оставшееся время потратить на обучение сотрудников заказчика, либо потратить день на развертывание Hyper-V?
Huawei и DataCore объявили о партнерстве в области Software Defined Storage и hyperconverged систем.
DataCore Software, как мне кажется, не очень хорошо известны на российском рынке, но эта компания очень давно работает на рынке программных реализаций систем хранения и ее продукт SANsymphony активно конкурирует с такими системами как, например, Falconstor NSS.
Конвергентная система состоит из серверов Huawei FusionServer RH с предустановленным программным обеспечением DataCore SANsymphony и поддерживает различные гипервизоры (Hyper-V и VMware). Максимальная конфигурация включает 64 узла в кластере, а минимально необходимо только 2 узла, чтобы обеспечить отказоустойчивость. Решение не ограничивается простым кластером - за счет синхронной репликации на расстояниях до 100м обеспечивается катастрофоустойчивость в распределенном кластере. При правильной организации, полный сбой на одной из площадок не приведет к остановке всей инфраструктуры. Кроме того, поддерживается и асинхронная репликация - все это позволяет строить полноценные катастрофоустойчивые решения.
DataCore Random Write Accelerator позволяет существенно ускорить операции записи за счет использования быстрых SSD дисков, а многоуровневое хранение (multi-tiering) повысит не только скорость работы, но и эффективность использования дискового пространства.
Отличительной особенностью данного решения является то, что заказчик не ограничен в использовании лишь встроенных дисковых ресурсов (и DAS полок). SANsymphony это, по сути своей, еще и виртуализоватор СХД, поэтому в систему можно подключать как имеющиеся, так и новые системы хранения. Не секрет, что в SDS довольно низкая утилизация дискового пространства - в силу изолированности узлов требуется, как минимум, две копии данных плюс дополнительные резервы на снапшоты и пр. Использование внешних СХД может увеличить утилизацию дискового пространства, при этом, управление ресурсами будет по-прежнему сосредоточено в одном месте.
Единственное, что меня всегда немного “напрягало” в SANsymphony это то, что он работает в Windows среде, но, с другой стороны, StarWind тоже работает и ничего :)
Учитывая, что сейчас Huawei может предложить практически любое оборудование, начиная от серверов и СХД, заканчивая инженерными системами в ЦОД, данное решение позволяет получить законченную конвергентную систему от одного вендора, которая отлично масштабируется и сможет закрыть практически все требования. А уж если вспомнить про текущую политическую ситуацию, такое решение от азиатского вендора может оказаться весьма и весьма интересным как для "станционных" компаний, так и для тех, кто опасается возможных ограничений.
Мы рады пригласить Вас на семинар, проводимый компаниями Microsoft и Тринити, посвященный теме:
«Построение систем высокой доступности»
Одна из основных задач IT – это повышение доступности сервисов, которые предоставляются пользователям. Данный круглый стол посвящен теме построению систем высокой доступности с помощью технологий виртуализации компании Microsoft и ее партнеров. В рамках семинара будут рассмотрены как решения Microsoft, так и сторонние прикладные решения, расширяющие их функционал.
Мероприятие состоится 19 октября - (с 09:30-13:00) по адресу ул. Крылатская, д.17, корп. 1., бизнес центр «Крылатские холмы»
Программа:
09:30 – 10:00 Утренний кофе, регистрация 10:00 – 11:30 Как построить систему высокой доступности и нужна ли для этого виртуализация? 11:30 – 12:00 Перерыв на кофе 12:00 – 13:00 Средства повышения доступности приложений в виртуальной среде Microsoft Hyper-V
Будем рады видеть Вас!
Участие в семинаре бесплатное, просьба для регистрации направить письмо по адресу s.sosunova@trinitygroup.ru.
История придуманная и любые совпадения с реальными персонажами являются случайными (хотя и вполне вероятными).
Жил да был системный администратор, работал себе в небольшой компании, серверов у него в услужении было всего ничего – ну пусть будет 4 штуки, скажем. На серверах все стандартно, везде Windows Server установлен да и приложения на нем всякие работают – и контроллер домена, и файловый сервер, и почта, и SQL тоже был.
Жил бы наш админ, да и горя бы не знал, только как случись какая неполадка в его хозяйстве, так сразу его под белы рученьки на ковер к начальству ведут и ругают на чем свет стоит. А он, бедный, только руками разводит да слезно просит бюджет увеличить, чтобы большую СХД купить – без нее никак у него не получится все задачи в виртуальную инфраструктуру перевести, обеспечив тем самым большую отказоустойчивость. Начальство же ему в ответ, хмуря брови - “Нет! Тебе лишь бы деньги казенные в расход пустить! Мы вон тебе серверов купили отличных уже недавно! А нагрузка, сам говоришь, процентов 10 от силы. Да как у тебя язык-то поворачивается о таком просить?! Кризис же на дворе! Поди прочь, с глаз долой и сделай срочно, чтобы все работало!”.
И после таких разговоров шел обычно админ, понурив голову, к себе в кабинет и думку думал, но решение никак не приходило. Он уже и прикинул, какая производительность для текущих задач нужна – действительно, если Hyper-V использовать, то и пары физических серверов хватит. Но все равно – нужен внешний сторадж, чтобы хранить данные виртуальных машин. Можно конечно на “лишнем” сервере сделать iSCSI target (благо вариантов таких полно сейчас, даже и бесплатных). Но что будет, если это сервер “рухнет”?! Тогда уж сразу можно заявление на стол, а голову в петлю. Резервные копии на второй сервер немного подсластят жизнь, да только остановка сервисов при сбое все равно будет слишком долгая. Как же быть?
И вдруг вспомнил админ, что совсем недавно читал в каком-то блоге :) про Sanbolic Melio 2010. Есть же там и специальная редакция для Hyper-V, цена которой начальство ну никак не расстроит! И поддержка iSCSI есть, и кластерная файловая система все проблемы с CSV томами снимет. Так может быть можно и два iSCSI хранилища в “зеркало” объединить, чтобы защититься от сбоев? А ведь и правда можно (в DataCenter версии Melio Suite)! Тут уж и работа закипела, освободил админ два сервера, настроил на внутренних дисках RAIDы, установил iSCSI target, настроил все. Поставил на серверы с Hyper-V Sanbolic Melio 2010 (покупать сразу не решился, поэтому получил сначала демо-версию, которая по функционалу от оплачиваемой и не отличается ничем, кроме ограничения на срок использования). Создал зеркало, отформатировал диски – и все!
После этого сбой любого из серверов Hyper-V приводил только к перезапуску виртуальных машин на “живом” сервере, а если использовать DataCenter редакцию Melio, то и сбой сервера iSCSI вообще никак на доступности сервисов не отражается – вторая половина зеркала берет всю нагрузку на себя.
И вот тут-то админ и понял, что значит завоевать уважение и благосклонность начальства – бюджет решения был минимизирован, имеющееся оборудование было полностью задействовано, отказоустойчивость повысилась многократно. Теперь можно и в отпуск отпроситься, не опасаясь что через два дня срочно вызовут, да и обругают за то что ничего не работает.
Вот такая вот сказка получилась. Правдивая? По моему мнению - более чем!
В весьма полезном блоге про технологии виртуализации Mirosoft вчера появился очередной пост, на этот раз посвященный копированию файлов на тома CSV. При копировании файла на общий кластерный ресурс (CSV диск) на различных узлах скорость очень сильно отличается. Причина в том, что если узел, на котором происходит копирование, является координатором тома CSV, все операции происходят локально и скорость максимальная. Если же узел координатором не является, то все операции записи перенаправляются на узел-координатор по сети. Конечно же такая проблема наблюдается только при копировании файлов – когда виртуальная машина работает со своим VHD файлом, все операции уже идут исключительно “напрямую”. Соответственно, чтобы минимизировать нагрузку, нужно сначала найти узел-владелец кластерного ресурса (либо через консоль Failover Cluster Manager, либо через powershell), а уже потом именно на этом узле произвести все необходимые операции с файлами. Но есть и другой выход! Я уже писал про него ранее – это кластерная файловая система Sanbolic MelioFS. При ее использовании все узлы имеют параллельный доступ к общему диску. Производительность уже совершенно не зависит от того, на каком узле мы осуществляем те или иные операции с файлами. “Младший” по функционалу бандл (и, что для многих весьма немаловажно, самый бюджетный) - Melio Virtualization Product Suite как раз и предназначен специально (и только) для хранения файлов виртуальных машин (как раз там и используются CSV тома, когда нет кластерной файловой системы). Помимо непосредственно файловой системы (которая кстати поддерживает и VSS), в состав пакета входит менеджер томов LaScala и средство для автоматической миграции файлов SILM. С помощью SILM можно переносить неиспользуемые данные на вторичное хранилище (на нем, при этом, вовсе не обязательно должна быть файловая система MelioFS). Общие диски могут быть подключены к серверам как по FibreChannel, так и по iSCSI (фактически не выдвигаются никакие дополнительные требования по сравнению с теми, которые есть при использовании CSV).
9го февраля IBM анонсировал новое лезвие HS22V. Название недвусмысленно намекает на то, что прицелом является виртуализация. Действительно, основное отличие от HS22 (которые уже заняли основную нишу в блейдах IBM), состоит в наличии 18 (а не 12ти) слотов под память. А память является, как известно, наиболее востребованным компонентом при внедрении виртуализации серверов – процессорной мощности зачастую бывает много, а памяти почти всегда не хватает.
Вместо двух hot-swap дисков предлагается использовать пару фиксированных 1.8” 50GB SSD дисков (поддерживается RAID-0 и RAID-1). Желающие могут добавить аппаратный RAID с батарейкой (впрочем, не думаю, что для данного лезвия это будет хоть как-то востребовано). Также уже традиционно присутствует разъем для USB накопителя с предустановленной Vmware ESXi (3.5 или 4). Что касается плат расширения, то здесь все осталось без изменений по сравнению с HS22. Базовые модели лезвий используют процессоры X5570 и E5540, можно также заказывать вариант с процессорами E5506 (но массово он поставляться не будет).
Для виртуализации весьма удобно использовать Virtual Fabric Adapter, про который я уже писал. Для тех, кому актуально использование FibreChannel, но уже есть прицел на FCoE и/или 10Гбит также есть хорошее решение - Virtual Fabric Extension Module.
Начало отгрузок HS22V планируются на 16е марта. Кроме того, в интернет просочилось название нового лезвия на процессорах Nehalem EX - HX5. Предполагается поддержка 4х процессоров на собственном чипсете eX5. Напомню, что текущую серию процессоров Xeon MP в лезвиях IBM не встретить – аргументом было повышенное энергопотребление и тепловыделение. А на Youtube давно уже можно найти совместный рассказ IBM и Intel о готовящемся чипсете и апдейте линейки 3850M2/3950M2.
С завидным постоянством вижу вот такого плана вопрос:
“Мы установили дисковую систему, создали один LUN, все настроили, подключили два сервера. На одном сервере файлы записываем, а на другом никаких изменений не видно. Да еще и ошибки какие-то странные. Что надо еще настраивать?”.
Причем, как это ни странно, технический уровень спрашивающих может быть очень разным, а вопрос один и тот же. А ведь, казалось бы, все очевидно: файловые системы (большинство), которые мы привыкли использовать (NTFS, EXT3, …) просто не умеют работать в таком “распределенном” режиме. Представьте, что на сервер А мы записали на диск файл, но каким образом об этом станет известно серверу B? Без специальной кластерной файловой системы, которая сообщит ему об этом – никак. И наиболее вероятным результатом (даже сравнительно короткого) такого “испытания” на обычной файловой системе будет полный ее крах. Поэтому даже и эксперименты проводить не стоит – работать не будет! А что тогда делать и нужно ли это вообще? В большинстве случаев (особенно если очень пристально посмотреть на задачу или заказчика :) ) такой функционал действительно оказывается ненужным и для совместного доступа к файлам достаточно использовать CIFS (в Windows) или NFS (в Linux). Но, тем не менее, существует и довольно много задач, где общий доступ к дисковому устройству если и не необходим, то очень важен. Как для более простой реализации, так и для лучшей производительности системы. Для того чтобы такой доступ обеспечить нам и нужна будет кластерная файловая система. Существует их довольно много, подавляющее большинство ориентировано на Linux/Unix (RedHat GFS, IBM GPFS, Lustre, HP Plyserve и т.п.), но и Windows не остался в стороне (Sanbolic MelioFS, HP Polyserve, IBM GPFS). Исторически решения под Linux использовались для HPC кластеров (и ряда других приложений), а под Windows в основном для обработки медиа-контента. Сейчас дисбаланс уже не так заметен – Windows работает на всех фронтах. Кроме того, все активнее внедряются системы виртуализации на базе Hyper-V в Windows Server 2008 и 2008 R2. И, если у основного конкурента (VMware) кластерная файловая система уже есть (VMFS), то в случае с Hyper-V нужно либо обходиться без нее, либо использовать сторонние продукты. Но даже и в случае с VMware разделяемая файловая система может очень пригодиться – например при использовании совместно с бесплатным VMware Server можно размещать образы виртуальных машин на общем дисковом ресурсе, что значительно упрощает миграцию и в разы снижает время простоя при сбоях.
Сегодня более подробно я остановлюсь на решениях компании Sanbolic. Помимо кластерной файловой системы MelioFS, в портфель продуктов постепенно добавлялись и другие решения – это и система управления томами LaScala, и SILM, и AppCluster (о них немного ниже), а выбрать что же именно нужно купить, чтобы получить искомый результат, становилось все сложнее. И, если представители интегратора в большинстве случаев хорошо понимают что и для чего нужно, то объяснить клиенту, что ему нужна не одна лицензия за 2000$, но к ней еще нужно докупить две лицензии по 1500$, было в некоторых случаях сложно. В настоящее время ситуация существенно упростилась и предлагается всего 4 лицензии: Melio Virtualization, Melio Professional, Melio Enterprise и Melio Data Center. Благодаря этому выбор оптимального решения стал гораздо проще.
Все четыре продукта включают в себя (помимо кластерной файловой системы) систему управления томами (volume manager) LaScala. Поддержка страйпинга и конкатенации позволяет получить высокопроизводительный том необходимого объема. Также во все бандлы входит система SILM (Simple Information Lifecycle Manager), которая, на основе заданных пользователем политик, может перемещать файлы между различными системами хранения. Например, файлы, к которым не было обращения более 10 дней, будут перенесены на более медленную дисковую систему. Важно отметить, что поддерживается “смешанный” режим работы – данные могут располагаться не только на томах MelioFS, но и на любых других дисках (в том числе и локальных).
Melio Virtualization ориентирован на заказчиков, которые внедряют у себя Hyper-V или VMware Server, и позволяет получить всем серверам доступ к общей дисковой подсистеме (iSCSI или FC) для размещения на ней образов виртуальных машин. Благодаря поддержке технологий Quick и Live Migration, а также отсутствию ограничения на число серверов в кластере, актуальность данного решения фактически прямо пропорциональна числу физических серверов Hyper-V.
Второй, ориентированный на виртуализацию продукт - Melio Professional. Он предназначен для развертывания отказоустойчивого высокопроизводительного кластера системы динамической загрузки образов операционных систем на базе Citrix Provisioning Services. На общей файловой системе хранится как база данных, так и сами vDisk вместе с файлами кэшей записи. Нужно помнить, что данный бандл имеет ограничение на включение максимум двух узлов в кластер (а использовать меньше и смысла не имеет).
Два оставшиеся варианта лицензий уже не являются такими узкоспециализированными и предназначены для широкого круга заказчиков, чьи задачи не ограничиваются только виртуализацией. Melio Enterprise поддерживает совместную работу до 4х узлов в одном кластере и имеет ряд ограничений по сравнению с “топовой” версией Melio Data Center. В частности, нет поддержки зеркалирования (RAID1) и Quality of Service. Обе версии позволяют создавать высокопроизводительные кластеры файловых серверов, в том числе и с поддержкой балансировки нагрузки (NLB). Разумеется поддерживается DFS и ACL. Возможность динамического расширения файловой системы и томов позволяет избежать лишних остановок сервиса для обслуживания системы. По мере роста требований к файловым серверам можно добавлять как серверы, так и системы хранения в существующий кластер, увеличивая тем самым как суммарную емкость, так и производительность системы в целом:
Также в состав обоих пакетов входит AppCluster Manager – средство управления active-active кластерами MS SQL, когда соответствующие базы данных размещены на разделяемой файловой системе. Конечно, это решение не позволяет (в силу архитектуры MS SQL) построить аналог Oracle RAC, но дает возможность обеспечить минимальное время переключения между серверами в кластере в случае сбоя, а также балансировать нагрузку между физическими машинами:В варианте Data Center AppCluster работает совместно с QoS, чтобы позволяя критичным базам иметь приоритет при работе с дисковыми ресурсами.
Для тех же кто использует Hyper-V есть еще зачастую весьма веская причина использования Enterprise или Datacenter версий – технология Pass-through I/O увеличивает производительность дисковой подсистемы так как не требуется оповещение остальных машин в Windows Failover кластере об операциях записи в виртуальных машинах.
Триальную двухнедельную версию можно получить, зарегистрировавшись на сайте Sanbolic. А купить и/или получить более подробную информацию, как обычно, можно у нас. :)
Oracle перестал открещиваться от виртуализации сторонними гипервизорами и заявил, что будет прикладывать усилия к тому, чтобы помочь пользователям локализовать проблему:
The use of platform vendors’ virtualization technologies (both software and hardware based) to host Oracle E-Business Suite 11i and R12 is covered by Oracle’s policy with regards to 3rd-party products – that is, they are ‘not explicitly certified, but supported’.
What this means is that while these technologies are not certified, Oracle will not turn away a customer reporting an issue solely due to the use of these technologies. When possible Oracle will triage and attempt to diagnose the issue reported – Oracle support may attempt to replicate the issue in a non-virtualized environment and work with the customer to verify if the problem exhibits in such an environment.
Разумеется, если окажется, что проблема вызвана гипервизором, то обращаться придется уже по другому адресу.
Это конечно большой шаг вперед, но открытым остается вопрос лицензирования - для x86 систем ограничить (лицензионно чисто) число процессоров в Oracle можно только для OVM. Остается надеяться, что эта идеология также будет пересмотрена в скором времени.
