The OpenNET Project / Index page

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

Создан альянс, который займется продвижением систем виртуализации на базе KVM

19.05.2011 11:08

Компании HP, IBM, Intel и Red Hat объявили о создании альянса Open Virtualization Alliance, который будет заниматься продвижением открытых систем виртуализации на базе технологии KVM (Kernel-based Virtual Machine), разрабатываемой компанией Red Hat.

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

О вступлении в альянс уже заявили такие компании как BMC Software, занимающаяся разработкой систем виртуализации и облачных решений, Eucalyptus Systems, разработчик Amazon EC2-совместимой облачной платформы Eucalyptus и Novell, разработчик дистрибутива SUSE.

В качестве причин, по которым KVM может быть интересен компаниям, использующим проприетарные решения, приводятся следующие:

  • Рекордная производительность, поддержка таких повышающих скорость работы технологий, как SR-IOV (Single Root I/O Virtualization), hugepages и асинхронный ввод/вывод;
  • Хорошая масшабируемость вплоть до 4096 ядер и 64 Тб памяти с возможностью запуска виртуальных машин с 64 виртуальными процессорами и 2 Тб оперативной памяти;
  • Не имеющая проприетарных аналогов система безопасности, основанная на SELinux;
  • Возможность тонкого управления политиками QoS (потребление CPU, памяти, пропускной способности сети и дискового ввода/вывода) и задание лимитов на потребление ресурсов в виртуальных машинах с помощью C-Groups (control groups);
  • Экономия средств, которая может составить до 80% в сравнении с проприетарными аналогами;
  • Открытая экосистема, которая позволяет делать выбор в пользу того или иного основанного на KVM решения, не привязывая потребителя к определенному поставщику или продукту.


  1. Главная ссылка к новости (http://www.openvirtualizationa...)
  2. OpenNews: Проект по разработке для Linux-ядра отдельного пользовательского KVM-инструментария
  3. OpenNews: Сравнение производительности KVM и VirtualBox
  4. OpenNews: Первый стабильный релиз OpenNode, платформы для развертывания окружений KVM и OpenVZ
  5. OpenNews: Релиз SPICE 0.6.3 и qemu-kvm 0.13.0
  6. OpenNews: Оценка вклада компаний в разработку системы виртуализации KVM
Автор новости: Evgeny Zobnin
Тип: К сведению
Ключевые слова: kvm, hp, ibm, intel, redhat, ova, virtualization
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (52) Ajax/Линейный | Раскрыть все сообщения | RSS
 
  • 1.1, uspenok (?), 12:58, 19/05/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Кто-нибудь знает, как оно на десктопе по сравнению с VirtualBox? "Рекордная производительность" распространяется или появляется только при n=1000ядер? И как насчёт видео драйверов gnome3 и прочие свистелки запустятся ?
     
     
  • 2.2, IvAnZ (?), 13:05, 19/05/2011 [^] [^^] [^^^] [ответить]  
  • +7 +/
    imho в любом случае на дескторе VirtualBox получше будет, т.к. заточен под десктоп
     
     
  • 3.10, pavlinux (ok), 14:18, 19/05/2011 [^] [^^] [^^^] [ответить]  
  • +8 +/
    Хороший ответ! 5+
     
  • 2.3, Аноним (-), 13:06, 19/05/2011 [^] [^^] [^^^] [ответить]  
  • –7 +/
    "Виртуальные системы" и "производительность" - это взаимоисключающие параграфы.

    Что до N ядер, то закон Амдала все еще действует. :)

     
     
  • 3.7, tavaaver (?), 13:37, 19/05/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Вы плохо учили математику в школе (или еще учите ее там?)

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

    Напомню, что зависимость производительности весьма нелинейная.

     
     
  • 4.11, pavlinux (ok), 14:26, 19/05/2011 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Напомню, что зависимость производительности весьма нелинейная.

    y = 0.22*x; Очень даже линейная, только не пропорциональная.

    Но это суммарная производительность, скажем за месяц.
    А короткие, пиковые значения, например при многопоточном,
    параллельном кодировании видео могут давать и y = x

     
     
  • 5.19, анонимище (?), 14:41, 19/05/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >y = 0.22*x; Очень даже линейная, только не пропорциональная.

    Таки предыдущий комментатор был прав

    >Вы плохо учили математику в школе (или еще учите ее там?)

     
  • 5.46, vovan (??), 12:02, 20/05/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    вааще-то у=к*х - это вполне себе линейная зависимость и прямая пропорциональность. Э-эээх, Павлинукс, школа же средняя ;)
     
     
  • 6.47, pavlinux (ok), 14:25, 20/05/2011 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > вааще-то у=к*х - это вполне себе линейная зависимость и прямая пропорциональность. Э-эээх,
    > Павлинукс, школа же средняя ;)

    Пропорциональными называются две взаимно зависимые величины,
    если отношение их значений остается неизменным.

    При одном процессоре, функция есть y = x, при двух и более y = kx,
    где к - выводиться из закона Амдала; И как из этого закона видно, k всегда разное.

    Так что, не пропорция.

     
  • 4.12, Lain_13 (?), 14:28, 19/05/2011 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Виртуализация принципиально не может повышать производительность — больше промежуточного кода. Виртуализация позволяет экономить на железе и обслуживании, и ставить тонкие клиенты везде, где это возможно.
    Можно повышать производительность самой виртуализации сводя количество промежуточного кода между железом и виртуальной машинкой к минимуму. В идеале к нулю, но это не везде возможно.
    Если те-же задачи, что выполняются на виртуальной машине, запустить в ОС хоста, то они выполнятся быстрее или в худшем случае с той-же скоростью.
     
     
  • 5.15, pavlinux (ok), 14:34, 19/05/2011 [^] [^^] [^^^] [ответить]  
  • +6 +/
    > Виртуализация принципиально не может повышать производительность — больше промежуточного
    > кода.

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

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

    Вы забываете про потери при IPC.
    Одна задача с параллельным кодом распределенная на два компа, пущай даже в 1Gb сети,
    ну никак не обработается быстрее одного двухпроцессорного.



     
  • 5.16, анон (?), 14:34, 19/05/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Виртуализация принципиально не может повышать производительность — больше промежуточного кода.

    Смотрите в книгу, видите фигу?
    Вам человек русским языком написал, что производительность _совокупности_ машин можно увеличить за счёт виртуализации, так как она позволяет использовать те ресурсы, которые остались бы незадействованными на отдельных физических машинах.

    Например, если отдельно взятый сервер расходует не 100% процессорного времени, его можно потеснить, посадив к нему ещё один. И в результате показатели производительности снизились бы, если относить их к двум серверам, но по факту значительно повысились, так как физический сервер теперь один.

     
     
  • 6.20, pavlinux (ok), 14:43, 19/05/2011 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >> Виртуализация принципиально не может повышать производительность — больше промежуточного кода.
    > Смотрите в книгу, видите фигу?
    > Вам человек русским языком написал, что производительность _совокупности_ машин можно
    > увеличить за счёт виртуализации, так как она позволяет использовать те ресурсы,
    > которые остались бы незадействованными на отдельных физических машинах.

    Ну это спорный вопрос, о качестве алгоритма.
    Если алгоритм вычисления числа Пи до триллионного знака можно распараллелить
    на 4 потока, но каждый при этом жрет 22% процессора, то нафига этот код размещать
    на разных машинах, когда на одной он загрузит комп всего на 88%

        

     
     
  • 7.24, ананим (?), 15:44, 19/05/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    а если у тебя с 6 по 1001 знак считаться может только на винде, а с 1002 по 27'000'000'000 на линухе? а первые 5 - только из банк-клиента?
    а если и винда, и линух, и банк-клиент при этом (и даже будучи оформлены в виртуалки) всё равно не съедают и 50% мощности одного физического сервера?


    зыж
    что вы всё про 100% и 100%?
    да 50% (в пиках до 80%) если и съедается, то хорошо.
    пограничные случаи подсчётов геномов при ядерных взрывах просьба не приводить - речь о мирном использовании виртуализации.

     
     
  • 8.38, pavlinux (ok), 01:15, 20/05/2011 [^] [^^] [^^^] [ответить]  
  • +/
    В мирных целях у неё одна задача - изоляция чего-нибудь от чего-нибудь Windows... текст скрыт, показать
     
     
  • 9.40, ананим (?), 01:33, 20/05/2011 [^] [^^] [^^^] [ответить]  
  • +/
    заметь, всё это на одном физическом сервере так что задач 2 прикупил памяти по... текст скрыт, показать
     
  • 9.44, sanDro (ok), 11:39, 20/05/2011 [^] [^^] [^^^] [ответить]  
  • +/
    В мирных целях у виртуализации на серверах задача повысить эффективность испол... текст скрыт, показать
     
  • 5.41, Michael Shigorin (ok), 02:48, 20/05/2011 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Виртуализация принципиально не может повышать производительность

    Ещё как может -- например, засунутый в dosemu дос может резко разогнаться за счёт кэширования линуксовым ядром I/O (или нормального сетевого стека). :)

    Насколько понимаю, при повторном использовании одинаковых страниц на I/O тоже можно сэкономить -- но тут сам не делал и вайтпаперов не попадалось.

     
  • 4.22, Аноним (-), 15:31, 19/05/2011 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Если б это было правдой, можно было бы соорудить бесконечное число виртуалок и р... текст скрыт, показать
     
     
  • 5.25, Аноним (-), 15:45, 19/05/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Этот будак не видит принципиальной разницы между производительностью, масштабируемостью и энергетической эффективностью.
     
     
  • 6.43, ioyurojh ndv (?), 10:42, 20/05/2011 [^] [^^] [^^^] [ответить]  
  • +/
    А мне показалось, что как раз он видит
     
  • 6.54, Аноним (-), 20:06, 23/05/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Этот будак

    Который их них? Освойте цитирование, чтоли.

     
  • 5.28, Мужик32 (ok), 15:57, 19/05/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > можно было бы соорудить бесконечное число виртуалок и разогнать производительность до бесконечности ;)

    Это врядли. В нашем мире бесконечна только вселенная.

     
     
  • 6.29, Aquarius (ok), 16:35, 19/05/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > В нашем мире бесконечна только вселенная.

    и то не факт

     
  • 6.39, pavlinux (ok), 01:18, 20/05/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >> можно было бы соорудить бесконечное число виртуалок и разогнать производительность до бесконечности ;)
    > Это врядли. В нашем мире бесконечна только вселенная.

    Из доказанного, только числа. :)

     
  • 2.14, VoDA (ok), 14:29, 19/05/2011 [^] [^^] [^^^] [ответить]  
  • +/
    VB вроде как клиентское решение, а KVM это решение для серверов.
     
  • 2.27, zerot (ok), 15:55, 19/05/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    uspenok
    использую KVM на десктопе для разных гостевых ОС на - поиграться. Тесты на производительность не проводил, раньше сидел на VirtualBOX, сейчас KVM меня вполне устраивает и по производительности, и по возможностям
     
  • 2.30, anonymous (??), 17:20, 19/05/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Кто-нибудь знает, как оно на десктопе по сравнению с VirtualBox?

    смотря для чего оно тебе там надо. если 3д-перделки крутить — даже не начинай. да и 2д-перделки тоже.

     
     
  • 3.35, anonymous (??), 00:15, 20/05/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Вот не надо брызгать слюной, cо SPICE все 2D просто летает (Fedora 15 RC).
     
  • 2.31, Funt (?), 17:52, 19/05/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Помнится когда в последний раз пытался пользоваться удручал очень маленький IO так и не стал разбираться с чем это было связанно, вин хр ставилась аж целый час
     
     
  • 3.33, anonymous (??), 18:26, 19/05/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Помнится когда в последний раз пытался пользоваться удручал очень маленький IO так
    > и не стал разбираться с чем это было связанно, вин хр
    > ставилась аж целый час

    это сколько лет назад было?

     
     
  • 4.34, Funt (?), 20:00, 19/05/2011 [^] [^^] [^^^] [ответить]  
  • +/
    2.6.34 ядрышко было пользовался еще на ArchLinux
     
     
  • 5.36, Dim (??), 00:48, 20/05/2011 [^] [^^] [^^^] [ответить]  
  • +/
    надо было использовать virtio
     
  • 1.4, name (??), 13:11, 19/05/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Долго тестировал KVM, сравнивал с XENом. К сожалению, он показал ОЧЕНЬ слабую производительность по IO, особенно по записи (потери до 40% от host машинки, в XenServere потерь вообще почти нет).
     
     
  • 2.5, Андрей (??), 13:24, 19/05/2011 [^] [^^] [^^^] [ответить]  
  • –1 +/
    имхо, одно дело файл-контейнер, а другое - iscsi или raid
     
  • 2.6, Андрей (??), 13:26, 19/05/2011 [^] [^^] [^^^] [ответить]  
  • –3 +/
    > Долго тестировал KVM, сравнивал с XENом. К сожалению, он показал ОЧЕНЬ слабую
    > производительность по IO, особенно по записи (потери до 40% от host
    > машинки, в XenServere потерь вообще почти нет).

    и да, xen и kvm - несколько разные архитектурно. xen, имхо, лучше с lxc сравнивать

     
     
  • 3.13, анон (?), 14:28, 19/05/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >и да, xen и kvm - несколько разные архитектурно. xen, имхо, лучше с lxc сравнивать

    Што? lxc можно сравнивать разве что с openvz. Вообще, это просто такой механизм изоляции процессов, когда каждая группа процессов может получить свой сетевой стек, свой набор точек монтирования, своё пространство идентификаторов и так далее.
    xen даже в режиме паравиртуализации запускает отдельные копии ядра для каждого domu, не говоря уже о hvm режиме, использующем те же технологии, что и kvm.

     
     
  • 4.42, Michael Shigorin (ok), 02:57, 20/05/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Што? lxc можно сравнивать разве что с openvz.

    Вообще-то lxc от ovz и растёт. :)  А сравнивать их ещё можно с vserver.  Но лучше не с bochs/qemu/kvm/xen/vbox, конечно -- это другая весовая категория.

     
     
  • 5.53, vle (ok), 19:19, 23/05/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >> Што? lxc можно сравнивать разве что с openvz.
    > Вообще-то lxc от ovz и растёт. :)

    Откуда дровишки? И это, vserver/openvz на cgroup/lxc уже переписали?

     
     
  • 6.55, Michael Shigorin (ok), 23:12, 23/05/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >>> Што? lxc можно сравнивать разве что с openvz.
    >> Вообще-то lxc от ovz и растёт. :)
    > Откуда дровишки?

    lxc использует те куски, которые народ @openvz (и, помнится, из linux-containers@) замержил в основную ветку ядра.  Не совсем точно выразился -- "lxc от _подмножества_ кода openvz и растёт": http://lwn.net/Articles/321971/ (Кирилл Колышкин AFAIK возглавляет команду OpenVZ).

    > И это, vserver/openvz на cgroup/lxc уже переписали?

    За vserver давно не слежу (могу коллегу спросить, если хочешь), а openvz для >2.6.18 (кажется, в районе 2.6.24) перепирали на уже смерженую функциональность -- я хорошо прочувствовал по тому, как vzctl set --cpus сломался (сейчас уже иначе сделали): http://bugzilla.openvz.org/show_bug.cgi?id=1462

     
     
  • 7.56, vle (ok), 23:40, 23/05/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > а openvz
    > для >2.6.18 (кажется, в районе 2.6.24) перепирали на уже смерженую функциональность
    > -- я хорошо прочувствовал по тому, как vzctl set --cpus сломался
    > (сейчас уже иначе сделали): http://bugzilla.openvz.org/show_bug.cgi?id=1462

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

     
  • 3.23, Аноним (-), 15:33, 19/05/2011 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > xen, имхо, лучше с lxc сравнивать

    Сравнивать полновесный виртуализатор способный грузить разные операционки с разными ядрами с легкими но быстрыми контейнерами?! С дуба рухнули?!

     
  • 2.8, anonymous (??), 13:56, 19/05/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Долго тестировал KVM, сравнивал с XENом.

    И кто у тя был гостем ? Я надеюсь виртио пихал ...

     
  • 2.17, анон (?), 14:36, 19/05/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Долго тестировал KVM, сравнивал с XENом. К сожалению, он показал ОЧЕНЬ слабую
    > производительность по IO, особенно по записи (потери до 40% от host
    > машинки, в XenServere потерь вообще почти нет).

    Методика тестирования не описана -> вы говорите пустые слова.

     
  • 2.18, миха228 (?), 14:38, 19/05/2011 [^] [^^] [^^^] [ответить]  
  • +/
    по IO производительность у kvm не хуже xen, часто лучше
    осильте уже документацию, ее даже фроникс осилил, а у горе-тестеров все еще "к сожалению"...
     
  • 2.37, Dim (??), 00:50, 20/05/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Долго тестировал KVM, сравнивал с XENом. К сожалению, он показал ОЧЕНЬ слабую
    > производительность по IO, особенно по записи (потери до 40% от host
    > машинки, в XenServere потерь вообще почти нет).

    virtio или ide? и что в гестах?

     
  • 2.45, sanDro (ok), 11:44, 20/05/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Долго тестировал KVM, сравнивал с XENом. К сожалению, он показал ОЧЕНЬ слабую
    > производительность по IO, особенно по записи (потери до 40% от host
    > машинки, в XenServere потерь вообще почти нет).

    Под какой нагрузкой? По моим сведениям Xen имеет нехорошую привычку проседать по IO с ростом колличества дисковых операций. И да. Что использовалось в качестве виртуальных дисков?

     
  • 1.32, srgaz (?), 18:14, 19/05/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Убунты и тд.. Открою для Вас секрет SPICE+KVM Наше Все!
     
  • 1.50, Аноним (-), 07:38, 23/05/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    при большом количестве сетевых пакетов, например если ставить гостем астериск xen падал с жутким грохотом и гость и хозяин, Причем на разном железе. ОС центос 5.5 версию кернела не помню. Перешел на KVM - и никаких проблем. С тех пор ксену как то не доверяю.

     
  • 1.51, Аноним (-), 14:37, 23/05/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    До энтерпрайза еще не дорос. Слезаем с kvm-а - уж слишком много проблем с ним.
     
     
  • 2.52, АнонимусРекс (?), 14:44, 23/05/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > До энтерпрайза еще не дорос. Слезаем с kvm-а - уж слишком много
    > проблем с ним.

    вы просто не знаете как его готовить. если есть конкретный список проблем, можно попробовать разобраться

     
  • 1.57, lucentcode (ok), 19:39, 24/05/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    На моём CPU KVM не пашет, требует аппаратной виртуализации. Юзаю Qemu и VirtualBox.
     

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



    Спонсоры:
    MIRhosting
    Fornex
    Hosting by Ihor
    Хостинг:

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