The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Увидел свет эмулятор QEMU 0.15

09.08.2011 22:57

Анонсирован релиз системы эмуляции аппаратного обеспечения и виртуализации QEMU 0.15. В подготовке новой версии приняло участие 150 разработчиков, по сравнению с прошлым выпуском внесено 1800 изменений, добавлено около 100 тыс. строк кода. В качестве эмулятора QEMU позволяет запустить программу собранную для одной аппаратной платформы на системе с совершенно иной архитектурой, например, выполнить приложение для ARM на x86-совместимом ПК. В режиме виртуализации в QEMU достигается производительность выполнения кода в изолированном окружении близкая к нативной системе, за счет прямого выполнения инструкций на CPU и задействования гипервизора Xen или модуля KVM.

Ключевым изменением QEMU 0.15 стала интеграция в состав наработок проекта Xen, что привело к значительному повышению качества поддержки режима виртуализации с задействованием гипервизора Xen. Изначально инструментарий и набор драйверов для обеспечения работы гипервизора Xen базировался на форке кода QEMU. Для того, чтобы собрать все накопленные с момента форка изменения и оформить их для возврата в родительский проект, понадобился год работы. Возврат изменений затрудняло большое число дублирующего кода с реализацией одних и тех же возможностей, созданных как силами QEMU, так и разработчиками Xen. Проделанная работа по слиянию общих кодовых баз пойдет на пользу обоим проектам, за счет прекращения выполнения двойной работы и переходу к более тесному сотрудничеству.

Основные улучшения:

  • Синхронизация поддержки KVM с проектом qemu-kvm: Портированы многочисленные исправления, накопленные в рамках проекта qemu-kvm. Синхронизирован код поддержки многопоточной модели. Базовый код поддержки KVM теперь будет совместно использоваться и развиваться одновременно для qemu и qemu-kvm.
  • Для использования инструментов для системы виртуализации KVM больше не требуется наличия внешних заголовочных файлов Linux-ядра, все поддерживаемые функции KVM теперь встроены в итоговый исполняемый файл;
  • Для архитектуры x86 в KVM обеспечена поддержка процессорных расширений SMEP (Supervisor Mode Execution Protection) и расширенных функций CPU VIA. Обеспечено корректное сохранение счетчика точного времени (TSC, Time Stamp Counter) при проведении миграции гостевых окружений. Переработана поддержка MCE (Machine Check Exception);
  • Поддержка новых целевых (эмулируемых) архитектур Lattice Mico32 (LM32) и UniCore32. Добавлена базовая поддержка эмуляции платы LM32 EVR и полная поддержка Milkymist SoC, включая функции отображения видео;
  • ARM: Исправлены недоработки в реализации эмуляции используемых в процессорах ARM расширений Neon, инструкций ARMv6 и ARMv7, операций с плавающей запятой. Добавлена поддержка SA-1110/SA-1100. Реализована эмуляция двух машин: ARM Versatile Express ("vexpress-a9") и Sharp Zaurus SL-5500 ("collie");
  • SPARC: Улучшения в OpenBIOS сделали возможным загрузку Solaris 8. Исправление ошибок в эмуляторе Sparc32 и Sparc64. Исправление реализации инструкций sdivx и udivx позволило обеспечить загрузку HelenOS в режиме командной строки;
  • Обеспечена поддержка сборки кода с реализацией хост-системы в режиме Thumb (сокращенная система команд) процессоров ARM;
  • Улучшена работа драйверов virtio-serial и virtio-balloon. Запрещено создавать несколько balloon-устройств, устранена утечка памяти при отсоединении устройства virtio-balloon, исправлена ошибка мешающая миграции после отсоединения устройства virtio-balloon;
  • Добавлена поддержка live-снапшотов в QMP (QEMU Monitor Protocol) при помощи команды snapshot-blkdev-sync;
  • Устранена проблема с излишним кэшированием размера носителя, что например, могло проявляться в показе размера ранее вставленного CD-ROM после смены диска;
  • В утилиту qemu-img для команд "convert" и "rebase" добавлена опция "-p" при указании которой наглядно отображается прогресс выполнения операции. Для команд "commit", "convert" и "rebase" добавлена опция "-t", позволяющая указать режим кэширования, который будет использован при открытии образа. Увеличена производительность выполнения операции преобразования образов.
  • Улучшена производительность создания и удаления внутренних снапшотов для блочных устройств qcow2;
  • Добавлена возможность увеличения размера уже созданных образов виртуальных машин QED (QEMU Enhanced Disk) при помощи команды "qemu-img resize". Повышена устойчивость образов QED от повреждения в результате аварийного завершения, например, после выключения питания;
  • Для образов VMDK обеспечена поддержка субформата monolithicFlat;
  • В Sheepdog, распределенном хранилище для инфраструктуры виртуальных серверов на базе QEMU/KVM, добавлена возможность предварительного резервирования места в процессе создания образов виртуальных машин;
  • Для поддержки RBD теперь используется высокоуровневая библиотека librbd вместо librados;
  • В код эмуляции IDE-подсистемы добавлена поддержка команды TRIM. Вместо одного общего устройства ide-drive, для жестких дисков теперь используется устройство ide-hd, а для CD-ROM - ide-cd. По аналогии для SCSI-устройств вместо scsi-disk для жестких дисков теперь используется scsi-hd, а для CD-ROM - scsi-cd;
  • Многочисленные исправления, связанные с обеспечением совместимости эмулятора CDROM со спецификацией ATAPI. Проведен значительный рефакторинг кода;
  • Для перенаправления пакетов ICMP ECHO (ping) задействована появившаяся в ядре Linux 3.0 возможность создания непривилегированных ICMP-сокетов. Налажена поддержка DHCP в режиме host-only;
  • В QMP (QEMU Monitor Protocol), базирующегося на JSON асинхронного протокола для взаимодействия пользовательских приложений с QEMU, добавлена поддержка команд inject-nmi и snapshot-blkdev-sync, устранены проблемы с работой парсера JSON, добавлен агент выполнения команд в гостевых окружениях;
  • В код поддержки операционной системы Linux (linux-user) добавлена поддержка системных вызовов ppoll, sched_{g,s}etaffinity, epoll, pselect6 и prlimit64. Добавлена поддержка целевых платформ s390x и unicore32;
  • В список обязательных для сборки зависимостей добавлена библиотека glib-2.0, а в список опциональных зависимостей добавлены libcurl 7.15.4 и spice 0.6.0.


  1. Главная ссылка к новости (http://lists.gnu.org/archive/h...)
  2. OpenNews: Для QEMU подготовлена поддержка USB 2.0 и возможность проброса USB устройств по сети
  3. OpenNews: В QEMU интегрированы наработки, созданные в рамках проекта Xen
  4. OpenNews: Реализация поддержки OpenGL ES для QEMU
  5. OpenNews: Релиз эмулятора QEMU 0.14
  6. OpenNews: Релиз эмулятора QEMU 0.13
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/31441-QEMU
Ключевые слова: QEMU, emulator
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (27) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.2, ubuntulyb (ok), 01:29, 10/08/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Для использования инструментов для системы виртуализации KVM больше не требуется наличия внешних заголовочных файлов Linux-ядра

    Отлично

     
  • 1.12, Аноним (-), 08:48, 10/08/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Кто использует, поделитесь, как там со скоростью работы? Можно сравнить с VMWare и VirtualBox? Есть такая интересная штука - SPICE, к которой я присматриваюсь. Это работает только с виртуалками под QEMU. Если QEMU может быстро работать с виртуальным жестким диском, то Citrix может идти лесом...
     
     
  • 2.15, dalco (ok), 09:22, 10/08/2011 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Очень шустрая. С виртуальными дисками работает отлично. Главное, помнить два правила:

    1. Не держать файлы виртуальных дисков на btrfs - иначе тормоза жуткие (авторы btrfs об этом баге в курсе и усердно пытаются его исправить). Все остальные варианты (отдельный LVM-раздел, файл в ext4 и прочее) работают отлично.

    2. Использовать, по возможности, virtio-драйверы жестких дисков в гостевых машинах (более-менее новыми ядрами линя они поддерживаются, под винду драйвера тоже есть http://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/bin/). Эмуляция обычного IDE тоже поддерживается, но жрет много больше ресурсов.

     
     
  • 3.16, gkv311 (ok), 10:05, 10/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >Все остальные варианты (отдельный LVM-раздел, файл в ext4 и прочее) работают отлично.

    А вариант FUSE с NTFS тоже не таит подводных камней?

     
     
  • 4.17, all_glory_to_the_hypnotoad (ok), 10:26, 10/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    на самом деле есть всего один нормальный путь разадчи дисков вируалкам (независимо от гипервизора) - через менеджер томов. В линуксе это lvm или ручная нарезка разделов. Всё остальное будет тормозить по определению
     
     
  • 5.19, dalco (ok), 11:06, 10/08/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > на самом деле есть всего один нормальный путь разадчи дисков вируалкам (независимо
    > от гипервизора) - через менеджер томов. В линуксе это lvm или
    > ручная нарезка разделов. Всё остальное будет тормозить по определению

    Не согласен.

    По скорости raw-диск на отдельном LVM разделе и qcow2-файл на ext4 практически идентичны (если верить недавним тестам btrfs-разработчиков).

    К тому же qcow2-файл на ext4 по умолчанию занимает ровно столько места, сколько реально есть данных на диске виртуалки, а не столько, сколько ей обещано ;) Imho, это крайне удобно, когда у вас виртуалка далеко не одна и точный расчет потребного ей места невозможен.

    Например, мои виртуалки просят 104 гига дискового пространства, реально занимая только 63. Считай, 40% экономии места на диске.

    В общем, теория далеко не всегда совпадает с практикой :)

     
     
  • 6.21, anonymous (??), 12:50, 10/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Не согласен, LVM гораздо удобнее, если виртуалок больше чем одна, и они однотипные. Ставится одна виртуалка, после чего раздел клонируется средствами LVM. Плюсы - полное использование одинаково занятого места (у меня на деле было 10 виртуалок, каждая из которых имела по 10 гигабайт общих данных с другими виртуалками, при этом все виртуалки имели размер в 25 гбайт), максимально быстрое копирование, бескостыльное монтирование раздела виртуалки к хостовой системе. Юзал ксен.
     
     
  • 7.22, dalco (ok), 13:20, 10/08/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Для однотипных виртуалок - очень даже может быть, что вы и правы. У меня же разброд и шатание - разные дистрибутивы линя на разных ядрах, да плюс ко всему win2k8 встречается.

    P.S. В идеале, когда-нибудь, в светлом будуЮщем, все эти виртуалки будут неплохо жить на btrfs со сжатием, дедупликацией, снапшотами и прочими ништяками.

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

     
  • 7.25, Аноним (-), 15:56, 10/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Не согласен, LVM гораздо удобнее, если виртуалок больше чем одна, и они
    > однотипные.

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

     
     
  • 8.27, all_glory_to_the_hypnotoad (ok), 18:09, 10/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    точно так же можно копировать том на любую машину Или что тут такое, виндовс юз... текст свёрнут, показать
     
  • 7.34, another_anoymous (?), 16:06, 11/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Xen -это Citrix или xcp?
    Потому как в обычном LVM такой возможности не видел.
     
  • 6.26, all_glory_to_the_hypnotoad (ok), 18:06, 10/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Например, мои виртуалки просят 104 гига дискового пространства, реально занимая только 63. Считай, 40% экономии места на диске.

    никакой экономии нет. Если обещали виртуалкам 104 гига, а по факту занимают 63, то минимум 41 гб просто обязан держать свободными в резерве. Иначе как-то совершенно неожиданно упадут все виртуалки в час-пик, когда им наконец таки понадобятся остатки места.

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

     
     
  • 7.29, dalco (ok), 21:09, 10/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Не буду я держать 41 гб в резерве по двум причинам.

    Во-первых, резерв и так гораздо больше (но им не только виртуалки могут воспользоваться);)

    Во-вторых, виртуалкам место было выделено по принципу плюс-минус лапоть. В моем случае, я мог каждой "пообещать" и по терабайту дискового пространства. Они съели столько, сколько каждой нужно и на этом успокоились, далее каких-либо значительных изменений для уже созданных виртуалок не предвидится. Мне никто не мешает отресайзить виртуальные диски до тех величин, что есть сейчас, но я просто не вижу в этом смысла.

    P.S. И нефиг гнать на Сатану. Худший враг человека - он сам :)

     
  • 5.24, Аноним (-), 15:53, 10/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > на самом деле есть всего один нормальный путь разадчи дисков вируалкам

    Обоснуйте.

    > ручная нарезка разделов. Всё остальное будет тормозить по определению

    Опять же, а обосновать этот масштабный вывод?

     
     
  • 6.28, all_glory_to_the_hypnotoad (ok), 18:10, 10/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    это слишком очевидно чтобы писать обоснования
     
  • 5.41, Онаним (?), 17:34, 15/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Да? А снапшоты у Вас будут только состояния диска? Или состояния всей ОС включая ОП? Вот в qcow2 контейнере будет снапшот всей ОС! И это преимущество полностью перекрывает все преимущества размещения дисков гостей напрямую в lvm.
     
  • 4.18, dalco (ok), 10:52, 10/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    to gkv311:

    А фиг его знает, у меня NTFS на линуксовых машинах давно нет. Как там сейчас с потреблением ресурсов у ntfs-3g - неизвестно. В конце-концов, создай две идентичные машины, одну на ntfs, вторую на ext4 и сравни. Подозреваю, что особой разницы не будет, если виртуалка постоянно с диском не работает.

     
     
  • 5.35, WhereWolf (?), 17:51, 11/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Да как и раньше - Скорость при копировании с ntfs на ext4 - не более 30 Мб/с, четырехядерник нагружается iowait на 70%
     
     
  • 6.38, mmx_ (?), 17:57, 13/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Да как и раньше - Скорость при копировании с ntfs на ext4
    > - не более 30 Мб/с, четырехядерник нагружается iowait на 70%

    Кто ж вам виноват , что вы занимаетесь такими извращениями ?

    Конкретно  virtio + ext4  (все на lvm в хост-машине) - скорость отличная.

     
  • 3.23, Аноним (-), 14:48, 10/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    А также:
    3. Если вы пользуетесь дисками в формате QCOW2, проверьте режим кеширования. По умолчанию используется ЖУТКО тормозящий режим кешированя. Поэтому снапшот может занимать чуть более чем вечность.

    В остальном - считает довольно хорошо и быстро. Заметно проседает:
    - Скорость графики vs реальное железо. Ну и хрен с ней, собственно.
    - Скорость дисков vs реальное железо.

     
  • 3.33, chemtech (ok), 13:18, 11/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Весной пытался установить Win2k3 в (KVM) QEMU с жестким диском virtio. Эмулировал дискетку  virtio-win-1.1.XX.vfd - винда так жесткий и не увидела.
    Сейчас не тестил.
     
  • 2.37, mmx_ (?), 17:55, 13/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
        Отлично работает.  
    Как минимум не медленнее, а то и быстрее.

    > Кто использует, поделитесь, как там со скоростью работы? Можно сравнить с VMWare
    > и VirtualBox? Есть такая интересная штука - SPICE, к которой я
    > присматриваюсь. Это работает только с виртуалками под QEMU. Если QEMU может
    > быстро работать с виртуальным жестким диском, то Citrix может идти лесом...

     

  • 1.20, hummermania (ok), 11:26, 10/08/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Отправляю флюиды добра разработчикам обоих проектов. Ресайз образов диска кстати жду уже. На железе с поддержкой виртуализации QEMU-KVM - конечно силен. Щас тестирую на нем седьмой оффтопик и XenCloudPlatform - да да не смейтесь. Пока приходится его запускать на рабочем десктопе в виртуалке, чтобы потом веб-мордой тыкнуться и попробовать сбацать облачко. Будет отдельная железка -тогда да. А пока так. В общем тема хорошая и с распространением облаков всё более востребованная. Особенно когда планируете приватное корпоративное облако делать.
     
  • 1.32, VolanD (ok), 10:41, 11/08/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >[оверквотинг удален]
    > платформы на системе с совершенно иной архитектурой, например, выполнить приложение для
    > ARM на x86-совместимом ПК. В режиме виртуализации в QEMU достигается производительность
    > выполнения кода в изолированном окружении близкая к нативной системе, за счет
    > прямого выполнения инструкций на CPU и задействования гипервизора Xen или модуля
    > KVM.
    > Ключевым изменением QEMU 0.15 стала интеграция в состав наработок проекта Xen, что
    > привело к значительному повышению качества  поддержки режима виртуализации с задействованием
    > гипервизора Xen. Изначально инструментарий и набор драйверов для обеспечения раб...
    > URL: http://lists.gnu.org/archive/html/qemu-devel/2011-08/msg01277.html
    > Новость: http://www.opennet.me/opennews/art.shtml?num=31441

    На BSD работать будет?

     
     
  • 2.36, Аноним (-), 19:51, 11/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Тоже интересно.
     

  • 1.39, Аноним (-), 14:16, 15/08/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Есть железка управляемая по USB, драйвер для нее только под ветку Windows 98.
    С помощью QEMU я смогу рулить железкой через USB?
     
     
  • 2.40, Аноним (-), 14:17, 15/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Естественно установив Win98 в QEMU.
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру