Вышел Qemu 2.4

Наконец-то вышел Qemu 2.4. В большом списке изменений хотелось бы выделить поддержку VirtIO GPU, разработанного нашим коллегой David Airlie, горячее удаление памяти, улучшение в зеркалировании блочных устройств. Одновременно выпустили багфикс-релиз Qemu 2.3.1.

Вообще, несмотря на взрывной рост интереса к контейнерам, отметим, что старый конь борозды не испортит. Учитывая пока что нерешенные проблемы с безопасностью контейнеров, особенно в маргинальных дистрибутивах, без SELinux, у виртуализации будет своя ниша. Конечно, конкуренция решений тут лишь обостряется. Большие игроки медленно решаются что-то менять, но если решаются, то бесповоротно. Вы уже могли слышать, что пару месяцев назад Linode решил уйти с Xen на KVM (причем, отметьте, они утверждают, что KVM-виртуалки заметно быстрее Xen-виртуалок), но впереди еще миграция еще больших размеров, которую мы пока что ждем.

Итак, виртуализация не собирается уходить, и уже понятно, что завоевала некую стабильную долю среди всех решений. Де-факто стандартом для новинок становится Qemu, на котором смело экспериментируют. Например, Intel уже несколько месяцев, как анонсировала проект Clear Containers, в рамках которого ведется научно-исследовательская работа по оптимизации виртуальной машины с Linux-системой для запуска контейнеров. Они обнаружили неисследованное поле для оптимизации - загрузка и инициализация виртуальной машины. Т.к. Qemu декларирует поддержку операционных систем в общем случае, то по умолчанию загрузка виртуалки не сильно отличается от загрузки персоналки с Windows 95. Тот же 16-битный BIOS вместо UEFI, те же процедуры инициализации. А почему бы не изменить эту часть, выбросив поддержку операционных систем из 1980х и 1990х годов? После экспериментов с пересборкой Qemu и разработкой специального firmware, Paolo Bonzini официально объявил о выходе qboot, специальном firmware и инструкции для пересборки Qemu, позволявшим запустить исполнение виртуальной машины через 40 миллисекунд, вместо обычных 500-700. Дальше, конечно, время тратится на запуск ядра, initrd, init-процесс, но полсекунды сэкономить получилось!

Анонс qboot вызвал оживленное обсуждение. Понятно, что кое-чего при таких результатах еще нет, да и Paolo признался, что разработал прототип за 24 часа, и понятно, что SeaBIOS можно тоже подсушить, но 200 миллисекунд в SeaBIOS против 20 в qboot, это заметная разница. Можно ожидать, что qboot как таковый, использоваться будет незначительно - уж слишком это изменение инвазивно со своим требованием пересборки Qemu, но определенно стоит ожидать оптимизаций в SeaBIOS и возможно в Coreboot.