Судя по отсутствию комментов - сафсем нинужын???

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

Копипаста с опеннета такая копипаста :)

Давайте уже официально переименуем новостную ленту лора в официальное зеркало опеннета.

Кто протестил - отпишитесь, плиз, о впечатлениях.

А то срашно обновлять по живому

Копипаста? да ну? Каждое слово переделано и обороты предлоежений, не свисти. Может сам что-то полезное запостишь?

клевый инструмент, использую с удовольствием для KVM

Закройте люк, дует!

Вышел ещё в феврале, вообще-то.

Вышел действительно давно. Ставить обязательно, т.к. предыдущие версии висли почем зря. Настройка бриджей работает только под RedHat/CentOS с родственниками - завязана на формат конфигурационных файлов ОС.

пока не будет приличных драйверов для фенды - не нужен.

GTK+-

Ну нафига на сервер ставить иксы, и кучу либ? Неужели сделать веб морду тяжелее чем гтк? На худой конец curses.

>Ну нафига на сервер ставить иксы, и кучу либ? Неужели сделать веб морду тяжелее чем гтк? На худой конец curses.

ssh -X

virt-manager замечательно по ssh подключается без необходимости поднимать иксы на сервере. Вы что-то в матчасти упустили.

KVM - это и есть Qemu. Вернее, всего лишь акселератор для него. Поправьте новость.

KVM - это не QEMU ни разу. Это всё равно что сказать: графическая карта ATI Radeon есть акселератор для X-Windows. Обалдеть просто! QEMU ямеет работать с кучей ядерных модулей, в т.ч. с XEN. KVM умееет работать вообще без всякого QEMU. Их объединяют в один пакет просто потому, что в 99 случаях из 100 их используют в связке, только и всего!

> PyGTK
Дык, космонавт же сказал всем писать на этом, видишь, даже Red Hat начал.

По поводу Virt-Manager: всё бы хорошо, если бы он не был написан на Python и не выдавал длинный тупой трейс ошибок кода при каждом неудобном для Virt-Manager действии. Только очень тупые программы не имеют даже самых элементарных обработчиков ошибок, выдающих вменяемые сообщения. Собственно, эти очень тупые программы делятся на два типа: написанные на Java быдло-индусо-Java-кодерами и написанные на Python быдло-индусо-питоно-кодерами.

>Каждое слово переделано и обороты предлоежений

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

Может сам что-то полезное запостишь?

<img src=«петросян.png» alt=«Отличная шутка!»>

>Ну нафига на сервер ставить иксы, и кучу либ? Неужели сделать веб морду тяжелее чем гтк? На худой конец curses.

Для Ъ есть чудесная программа virsh с аналогичными (и даже большими) возможностями.
Интерфейс — чистая командная строка.

Судя по отсутствию комментов - сафсем нинужын???

нинужын - очередная гуйня для ниасиливших virsh (который тоже нужен не всегда), да еще и тянет за собой пол-гнома, чтоб ему -

Calculating dependencies... done!
[ebuild  N    ] gnome-base/gnome-common-2.28.0  148 kB
[ebuild  N    ] dev-python/gnome-python-base-2.28.0  548 kB
[ebuild  N    ] gnome-base/libbonobo-2.24.2  USE="-debug -doc" 1,402 kB
[ebuild  N    ] gnome-base/gnome-keyring-2.28.2  USE="pam -debug -doc -test" 2,939 kB
[ebuild  N    ] dev-python/urlgrabber-3.1.0  77 kB
[ebuild  N    ] dev-python/pyorbit-2.24.0  USE="-debug" 287 kB
[ebuild  N    ] x11-libs/vte-0.22.5  USE="python -debug -doc -glade" 1,321 kB
[ebuild  N    ] net-libs/gtk-vnc-0.3.10  USE="python -examples -sasl" 484 kB
[ebuild  N    ] app-text/rarian-0.8.1-r1  USE="-debug" 317 kB
[ebuild  N    ] gnome-base/gnome-mime-data-2.18.0  USE="-debug" 593 kB
[ebuild  N    ] media-libs/libart_lgpl-2.3.20  USE="-debug" 296 kB
[ebuild  N    ] x11-misc/icon-naming-utils-0.8.90  69 kB
[ebuild  N    ] net-libs/libproxy-0.2.3-r3  USE="python -gnome -kde -networkmanager -webkit -xulrunner" 370 kB
[ebuild  N    ] net-libs/libsoup-2.28.2  USE="ssl -debug -doc -gnome" 705 kB
[ebuild   R   ] sys-fs/udev-151-r1  USE="devfs-compat extras* old-hd-rules (-selinux) -test" 0 kB
[ebuild  N    ] gnome-base/libgnomecanvas-2.26.0  USE="-debug -doc -test" 587 kB
[ebuild  N    ] dev-python/gconf-python-2.28.0  USE="-examples" 0 kB
[ebuild  N    ] app-emulation/virtinst-0.500.2  475 kB
[ebuild  N    ] gnome-base/gnome-mount-0.8-r1  USE="-debug -libnotify -nautilus" 494 kB
[ebuild  N    ] x11-themes/gnome-icon-theme-2.28.0  3,353 kB
[ebuild  N    ] net-libs/libsoup-gnome-2.28.2  USE="-debug -doc" 0 kB
[ebuild  N    ] gnome-base/gnome-vfs-2.24.2  USE="acl hal ssl -avahi -debug -doc -fam -gnutls -ipv6 -kerberos -samba" 1,816 kB
[ebuild  N    ] dev-python/libgnomecanvas-python-2.28.0  USE="-examples" 0 kB
[ebuild  N    ] gnome-base/gvfs-1.4.3  USE="bash-completion hal http udev -archive -avahi -bluetooth -cdda -doc -fuse -gdu -gnome -gnome-keyring -gphoto2 -samba" 1,234 kB
[ebuild  N    ] gnome-base/libgnome-2.28.0  USE="-branding -debug -doc -esd" 1,375 kB
[ebuild  N    ] dev-python/gnome-vfs-python-2.28.0  USE="-doc -examples" 0 kB
[ebuild  N    ] gnome-base/libbonoboui-2.24.2  USE="-doc -test" 939 kB
[ebuild  N    ] gnome-base/libgnomeui-2.24.2  USE="-doc" 1,492 kB
[ebuild  N    ] dev-python/libbonobo-python-2.28.0  USE="-examples" 0 kB
[ebuild  N    ] dev-python/libgnome-python-2.28.0  USE="-examples" 0 kB
[ebuild  N    ] app-emulation/virt-manager-0.8.3  USE="-gnome-keyring -policykit" 2,172 kB

Ну нафига на сервер ставить иксы, и кучу либ? Неужели сделать веб морду тяжелее чем гтк? На худой конец curses.

так оно ж не для сервера, а чтоб рулить

>virt-manager замечательно по ssh подключается без необходимости поднимать иксы на сервере. Вы что-то в матчасти упустили.

На админском локалхосте можно поднять virt-manager и рулить серверами?

На админском локалхосте можно поднять virt-manager

и рулить серверами?

Да! Вирт-манаджер это всего лишь гтк рожа к либвирту.
Вон у меня в нем видно кучку хостов с гипервизорами
квм-qemu и хен ....

KVM - это просто ветка QEMU...

> KVM - это не QEMU ни разу. Это всё равно что сказать: графическая карта ATI Radeon есть акселератор для X-Windows. Обалдеть просто! QEMU ямеет работать с кучей ядерных модулей, в т.ч. с XEN. KVM умееет работать вообще без всякого QEMU. Их объединяют в один пакет просто потому, что в 99 случаях из 100 их используют в связке, только и всего!

Во у чувака крыша едет!.......

KVM - это просто-напросто ещё одна ветка разработки QEMU. Или набор изменений для QEMU, позволяющий вместо эмуляции процессора использовать набор соотв. инструкций виртуализации современных процессоров (VMX и SVM), тем самым приводя скорость работы CPU в guest-системе до нативной. Используется при этом «помощь» в виде модуля ядра linux на host-машине.

QEMU сама по себе изначально 100% эмулятор, полностью в пользовательском процессе, без всяких модулей, работающий на куче всяких операционок включая windows. Была попытка ускорить работу с использованием модуля linux, соответствующая ветка называлась kqemu, однако она загнулась из-за общей кривости всей конструкции и из-за того что современные процессоры и kvm дают гораздо бОльший эффект и при этом всё вполне красиво получается.

Xen тоже использовал QEMU у себя внутри при работе в HVM-режиме, там, правда, была связка с гипервизором этого Xen'а, а не с модулями ядра. Впоследствие часть этого «форка» QEMU была влита в основную ветку QEMU, но не всё, часть так и идёт в виде отдельного форка внутри Xen'а.

Говорить о том что «kvm умеет работать без qemu» это всё равно что сказать что «машине колёса не нужны, двигатель и так работает» - т.к. kvm это и есть qemu, с добавками. Всё равно что сказать что «правки» (patch) работают и сами по себе без того к чему они предназначены.

В один пакет мы их объединять пытались - в том смысле чтобы отказаться вообще от qemu и оставить только kvm (как самостоятельная ветка разработки QEMU). Но толку от этого не получилось - в KVM не работает масса того что работает в «неправленном» qemu, например некоторые варианты arm/mips/sparc (QEMU используется для отладки софта для всяких маленьких устройств).

Вообще план - kvm как ветка разработки - в качестве «playground» для отработки собственно процессорных расширений, и она потихоньку перетекает в основную ветку QEMU. В дальнейшем планируется её закрыть, когда всё можно будет слить с «мамочкой».

Знаю всё это потому что активно использую и то и другое, и потому что являюсь сопровождающим (maintainer) пакета qemu-kvm в Debian.

/mjt

Может тогда поможешь привести в соответствие статью http://ru.wikipedia.org/wiki/QEMU а то в англоязычной больше расписано.

я не согласен с таким определением категорически
называть kvm «просто веткой», это как назвать локомотив «просто дрезиной»

qemu-kvm - полноценный VMM (гипервизор), но не в том смысле, что xen... ядро+kvm реализует контекс, а qemu i/o. все вместе - vmm (для каждой vm свой, да, в этом и отличие от xen)

qemu+kqemu (и тем более просто qemu) - обычные эмуляторы

создай лучше отдельную статью по kvm, так как это совершенно иная технология

А я согласен с тем кто непосредственно имеет к отношение к KVM и статья http://en.wikipedia.org/wiki/QEMU это подтверждает.

этот человек никакого отношения к kvm не имеет, иначе бы он такую чушь не порол. KVM - Kernel Based Virtual Machine и теоритически в его контексте можно запустить что угодно, но решили запустить qemu...

если вы где-то в статье на en.wiki нашли подтверждение этого тезиса - kvm=qemu - то остается только недоумевать. наверное я не тот английский учил в школе и последующие годы....

qemu - QEMU is a processor emulator

Integration in other virtualization solutions
- Kernel-based Virtual Machine (KVM) (By itself, it does not perform any emulation).

а если еще и учесть что на сайте kvm написано - KVM also requires a modified QEMU although work is underway to get the required changes upstream.
так вообще не понятно о чем тут может быть речь

в общем советую вам вообще ничего в вики про kvm не писать, дабы не плодить очередную колбасу из говна, которого там и так достаточно, а то еще немного и вы договоритесь до того, что ядро линукса - еще одна ветка разработки qemu... даже когда когда в апстрим qemu войдут все патчи (ой не скоро это будет), даже тогда KVM останется тем, чем оно является сейчас - VMM (гипервизором) - а не говноэмулятором процессора.

Но Вы ж не будете отрицать, что KVM без QEMU не конечный продукт для пользователя?

KVM - терминология

Тут спор ни о чём на самом деле. Вся «проблема» - в терминологии.

Кто-то называет KVM-ом только то что в ядре линукса - те три модуля, kvm.ko, kvm_amd.ko и kvm_intel.ko, которые собственно и реализуют тот самый гипервизор. Который у Xen'а живёт отдельно, а в этом случае - как часть ядра Linux в виде модулей ядра.

А кто-то под названием «KVM» понимает всё вместе - собственно «ядрёную» часть и соответствующую ему пользовательскую компоненту, которая и есть qemu+изменения.

Я имею в виду весь продукт целиком, некоторое работающее решение.

Собственно гипервизор (тот что модули в ядре) - он имеет небольшой размер и не сильно меняется от версии к версии. Но про него новости почти не пишут, он «выходит» вместе с ядром линукса как всякие драйверы, и даже бекпорты на более старые ядра нумеруются по версии ядра, из которого они были взяты (kvm-kmod-2.6.32 и т.д.)

Когда говорят что «вышла очередная версия KVM», обычно имеется в виду пользовательский компонент. Тот самый который построен на базе qemu и является веткой разработки.

Да, это факт что гипервизор можно использовать и с чем-то другим. Но только сам гипервизор, как и в случае с Xen'ом, — он неработоспособен сам по себе, ему нужна бааальшая обвязка чтобы что-то можно было запустить.

То же самое можно сказать и про Xen - сам по себе гипервизор бесполезен, и обычно под «просто Xen» (в отличие от «Xen гипервизор» или «Xen userspace») подразумевают именно всё вместе, причём если идти от официального сайта, туда же включается и dom0-ядро - входит в дистрибутив.

Между прочим, пользовательский компонент сейчас называется qemu-kvm - именно потому что это реально qemu, использующая гипервизор kvm. Нумерация версий у qemu и qemu-kvm тоже совпадают, сейчас стабильная 0.12.3, и очередная версия qemu-kvm выходит сразу после очередной версии qemu.

Сейчас идёт большая дискуссия по поводу слияния kvm-как-гипервизор с kvm-userspace, чтобы всё было в одном проекте. См. ветку обсуждения «[RFC] Unify KVM kernel-space and user-space code into a single project» в LKML или kvm@vger. В этом случае можно будет сказать что «вот этот проект - это KVM». Хотя я сомневаюсь что они таки сольются.

В контексте данной новости. Для управляющего софта (libvirt &Co суть менеджер виртуальных машин, т.е. система управления) в первую очередь важен тот кусок реализации VM, который можно «позвать» и «попросить» сделать что-то конкретное - запустить, остановить, «заморозить», создать, мигрировать и т.д. Этому libvirt пофигу все гипервизоры, в случае с kvm он зовёт собственно пользовательский компонент. И для libvirt нет разницы что звать - qemu и qemu-kvm, ибо это то же самое с точки зрения интерфейса (запустить/остановить/...)

Но ещё раз - это всё, на самом деле, вопрос терминологии.

Понятно что технология в случае qemu (как было изначально, с полной эмуляцией всего) и в случае с kvm (используем расширения процессора и работаем на нативной скорости) _сильно_ отличаются. Однако это отличие касается только части процессора и доступа к памяти, всё остальное (я опущу пока такие вещи как virtio) это чистый qemu. Ибо [V]M - это просессор, память и ввод-вывод - больше там ничего и нет... ;)

Собственно kvm так и задумывался, — «а что если нам поправить qemu и использовать там нативный CPU и SVM/VMX.. придётся какой-то модуль ядра сделать ещё, чтобы этими расширениями пользоваться..» — это сильно грубо, но показывает направление.

Надеюсь, что я разъяснил что я имел в виду. И надеюсь также что по всему что я изложил (и первый раз и сейчас) можно сказать что я немного разбираюсь в вопросе...

/mjt

да, разбираетесь, я немного просто вспылил, так что прошу прощения)))
но оно хоть и верно в принципе, но я бы не стал объединять эти 2 вещи в вики в одну статью, а сделал бы отдельно по квм...
то есть я по прежнему не назвал бы qemu=kvm, а скорей qemu+kvm(даже плюс qemu-kvm)

Собственно kvm так и задумывался, — «а что если нам поправить qemu и использовать там нативный CPU и SVM/VMX..

вот тут не соглашусь. это скорей про kqemu. а kvm делали именно как kvm, то есть сначала была Kernel-based Virtual Machine для которой сильно подпилили qemu (благодаря чему он и выжил, кстати сказать). емнип так оно было...

Спасибо за пояснения, уважаю знающих людей!