Если Вы имеете в виду контейнерную виртуализацию, то в Virtuozzo 7 эта уникальность никуда не исчезла. В приведённой Вами цитате речь идёт о гипервизоре – мониторе виртуальных машин.
Позвольте развеять Ваши заблуждения насчёт отсутствия совместимости с предыдущими релизами.
Во-первых, любой контейнер и любую VM, созданные на любой предыдущей версии Virtuozzo, можно смигрировать на 7.0. При этом контейнеры мигрируют с точно такой же скоростью как при миграции между двумя нодами с одной версией. В некоторых случаях с совсем старыми версиями возможно потребуется двухступенчатая миграция на промежуточную версию. Что же касается виртуальных машин, то несмотря на отличие в гипервизоре Vz6, на Vz7 предусмотрен простой и понятный механизм миграции виртуальных машин с Vz6. Миграция происходит медленнее, чем в случае с контейнерами, из-за необходимости конвертации диска в QCOW2.
Во вторых, что касается команд, в Vz7 есть все те же утилиты для управления виртуальными машинами и контейнерами, что и в предыдущих версиях, c сохранением их полной функциональности. Что же касается настроек, то поменялась только та часть из них, которая требовала переезда с ядра 2.6 на 3.10.
Разумеется настраиваем в процессе разработки. Но релизная версия ни коим специальным образом не настраивается для тестирования производительности. Берётся как есть.
Нет описания даже настолько базовых вещей, как железо, конфиги VM и паттерны нагрузок, или какие конкретно патчи для meltdown/spectre ставились и куда.
Согласен, конфигурацию железа и VM/контейнеров действительно стоит добавить. Каковы паттерны нагрузок в тестах vConsolidate и DVD Store, можно узнать из их описания, эта информация доступна в Интернете. То же касается и патчей для Meltdown/Spectre. Достаточно загуглить KTPI, IBRS, IBPB.
Тестирование Hyper-V 2012 — тоже своеобразный подход.
2012 R2 – это гостевая операционная система. Использовалась в тесте как наиболее распространённая на данный момент серверная версия Windows. Хостовый гипервизор – на базе Windows Server 2016. Виртуальные машины – второго поколения. То, что это не упомянуто в статье – наше упущение, исправимся.
Далее — vConsolidate.
Есть много мнений на этот счёт. Для нас это – нестареющая классика. Бенчмарк позволяет оценить одновременно производительность и плотность размещения виртуальных сред эмулируя внутри них разнотипную нагрузку: Java, Web, DB. Что 8 лет назад, что сейчас – это самые популярные виды нагрузок. Много ли было за это время изобретено новых бенчмарков, позволяющих делать то же самое для гостевых Windows?
«Продукты конкурентов», очевидно, используются в крайне широком круге задач, и для оптимизации под разные задачи в разных средах нужны разные настройки.
Безусловно. Если перемножить все задачи, среды, настройки и гипервизоры, мы получим великое множество конфигураций. И чтобы сравнить их все между собой, не хватит человеческой жизни. Именно поэтому мы используем дефолтную конфигурацию для каждого продукта, в том числе и для наших.
А конкретно про гипервизоры читать про дефолные настройки забавно еще и потому, что, скажем, дефолтная конфигурация VM там зависит даже не столько от самого гипервизора, сколько от системы управления.
Отчасти Вы правы. Такие базовые вещи как количество vCPU или vRAM мы конечно же приводим к одному знаменателю. Следующее, что может значительно влиять на производительность – типы эмулируемых виртуальных устройств – диска, сетевой карты и т.д. К сожалению мы не располагаем достаточным количеством времени, чтобы протестировать на предмет производительности все комбинации виртуальных устройств у конкурентов и поэтому полагаемся на дефолт, который предлагает система управления. Ведь согласитесь, если система управления создаёт VM c неоптимальной для производительности конфигурацией, то это – баг системы управления. Кроме того, в каких-то частных ситуациях мы полагаемся на общеизвестные факты о том какой тип устройства обладает более высокой производительностью. Например, известно, что на данный момент наилучшим решением блочного драйвера для KVM является Virtio-SCSI. Мы используем его у себя в качестве дефолтного и естественно, когда сравниваем себя с бесплатным KVM, и там используем Virtio-SCSI.
Какие именно условия Вас интересуют? В пределах одного графика условия для всех испытуемых одинаковы: один и тот же стенд клиент-сервер, одна и та же конфигурация железа. Каждый продукт тестируется с дефолтными настройками, за исключением тех настроек, которые описаны в легенде к графику.
Сила дефолта. Мы никак не настраиваем бесплатный KVM и продукты конкурентов. Берём их как есть. Если они не позаботились о том, чтобы дефолтная конфигурация их продукта обеспечивала максимальную производительность – это не наша вина, а их беда.
www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/downloads/eula/vmware-benchmarking-approval-process.pdf
Во-первых, любой контейнер и любую VM, созданные на любой предыдущей версии Virtuozzo, можно смигрировать на 7.0. При этом контейнеры мигрируют с точно такой же скоростью как при миграции между двумя нодами с одной версией. В некоторых случаях с совсем старыми версиями возможно потребуется двухступенчатая миграция на промежуточную версию. Что же касается виртуальных машин, то несмотря на отличие в гипервизоре Vz6, на Vz7 предусмотрен простой и понятный механизм миграции виртуальных машин с Vz6. Миграция происходит медленнее, чем в случае с контейнерами, из-за необходимости конвертации диска в QCOW2.
Во вторых, что касается команд, в Vz7 есть все те же утилиты для управления виртуальными машинами и контейнерами, что и в предыдущих версиях, c сохранением их полной функциональности. Что же касается настроек, то поменялась только та часть из них, которая требовала переезда с ядра 2.6 на 3.10.
Согласен, конфигурацию железа и VM/контейнеров действительно стоит добавить. Каковы паттерны нагрузок в тестах vConsolidate и DVD Store, можно узнать из их описания, эта информация доступна в Интернете. То же касается и патчей для Meltdown/Spectre. Достаточно загуглить KTPI, IBRS, IBPB.
2012 R2 – это гостевая операционная система. Использовалась в тесте как наиболее распространённая на данный момент серверная версия Windows. Хостовый гипервизор – на базе Windows Server 2016. Виртуальные машины – второго поколения. То, что это не упомянуто в статье – наше упущение, исправимся.
Есть много мнений на этот счёт. Для нас это – нестареющая классика. Бенчмарк позволяет оценить одновременно производительность и плотность размещения виртуальных сред эмулируя внутри них разнотипную нагрузку: Java, Web, DB. Что 8 лет назад, что сейчас – это самые популярные виды нагрузок. Много ли было за это время изобретено новых бенчмарков, позволяющих делать то же самое для гостевых Windows?
Безусловно. Если перемножить все задачи, среды, настройки и гипервизоры, мы получим великое множество конфигураций. И чтобы сравнить их все между собой, не хватит человеческой жизни. Именно поэтому мы используем дефолтную конфигурацию для каждого продукта, в том числе и для наших.
Отчасти Вы правы. Такие базовые вещи как количество vCPU или vRAM мы конечно же приводим к одному знаменателю. Следующее, что может значительно влиять на производительность – типы эмулируемых виртуальных устройств – диска, сетевой карты и т.д. К сожалению мы не располагаем достаточным количеством времени, чтобы протестировать на предмет производительности все комбинации виртуальных устройств у конкурентов и поэтому полагаемся на дефолт, который предлагает система управления. Ведь согласитесь, если система управления создаёт VM c неоптимальной для производительности конфигурацией, то это – баг системы управления. Кроме того, в каких-то частных ситуациях мы полагаемся на общеизвестные факты о том какой тип устройства обладает более высокой производительностью. Например, известно, что на данный момент наилучшим решением блочного драйвера для KVM является Virtio-SCSI. Мы используем его у себя в качестве дефолтного и естественно, когда сравниваем себя с бесплатным KVM, и там используем Virtio-SCSI.