The OpenNET Project / Index page

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

Компания Red Hat открыла исходные тексты технологии виртуализации SPICE

11.12.2009 00:01

Компания Red Hat объявила об открытии всех разработок связанных с технологией SPICE, развиваемых ранее компанией Qumranet в качестве проприетарного решение для десктоп-виртуализации. Компания Qumranet, занимающаяся координацией разработки открытой системы виртуализации KVM, была поглощена Red Hat в прошлом году. В настоящий момент поддержка SPICE интегрирована в продукт Red Hat Enterprise Virtualization for Desktops, находящийся на стадии бета-тестирования. Связанные со SPICE исходные тексты открыты под лицензией GPLv2, за исключением нескольких библиотек, распространяемых под лицензиями LGPL и BSD.

Протокол SPICE (Simple Protocol for Independent Computing Environment) используется для организации работы тонких клиентов, приложения которых выполняются на едином сервере виртуализации, на котором при помощи KVM может выполняться множество Windows или Linux десктоп окружений. SPICE позволяет организовать эффективную трансляцию вывода работающих в полноэкранном режиме приложений, имеющих доступ к локальным аудио и USB устройствам, принтерам и другому оборудованию, находящемуся на стороне тонкого клиента.

В отличие от таких протоколов как VNC (Virtual Network Computing), ICA (Citrix Independent Computing Architecture) и RDP (Microsoft Remote Desktop Protocol), в SPICE рендеринг содержимого экрана и обработка аудиопотоков производится на стороне клиента, а не на сервере, что, например, позволяет без лишней нагрузки на сервер просматривать видео или осуществлять VoIP звонки, делая для пользователя выполнение приложения на удаленном сервере максимально приближенным к локальному запуску программы.

Другой особенностью SPICE является возможность прозрачной балансировки нагрузки, позволяющей распределять выполнение приложений по разным серверам, автоматически адаптируясь к возможностям графической подсистемы на стороне клиента и загруженности сетевого окружения. Производительности сервера с 16GB ОЗУ достаточно для одновременной работы 50 клиентов выполняющих типичные десктоп приложения, или 40 клиентов 20% из которых просматривают видео или прослушивают аудио.

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

Текущие возможности:

  • Обработка и передача 2D графики;
  • Передача M-JPEG видеопотоков с эвристическим определением типа;
  • Поддержка различных алгоритмов сжатия изображений, включая UIC, LZ и GLZ.
  • Обработка и передача команд управления курсором;
  • Кэширование изображений, палитр и курсоров;
  • Возможность live-миграции виртуального окружения с одного сервера на другой без прерывания работы;
  • Наличие QXL и VDI драйверов для Windows;
  • Поддержка многомониторных конфигураций;
  • Наличие клиентского ПО для Linux и Window, возможность легкого портирования на другие платформы;
  • Двунаправленная передача аудио, звуковые данные сжимаются с помощью технологии CELT;
  • Поддержка шифрования, с использованием OpenSSL;
  • Два режима управления мышью - на стороне клиента (более дружелюбный пользователю) и сервера (более точное позиционирование и полная синхронизация);
  • Lip-sync - синхронизация видео и аудио потоков;
  • Возможность выполнения Spice agent, работающих в гостевом окружении и выполняющих задачи для клиента.

Находящиеся в разработке возможности:

  • Организация совместного использования сетевых ресурсов, например, принтеров;
  • Возможность организации совместной работы с буфером обмена на клиенте и сервере;
  • Возможность клиентам пробрасывать USB устройства и CD привода на сервер;
  • Direct Draw - организация прямого вывода на экран;
  • Разработка дружественной пользователю системы конфигурирования;
  • Добавление поддержки выбора активного экрана клиентом (переключение вывода на другие экраны);
  • Поддержка акселерации видео
  • Поддержка 3D-акселерации
  • Создание клиента для MacOS X.


  1. Главная ссылка к новости (http://www.redhat.com/about/ne...)
  2. OpenNews: Red Hat приобрела компанию Qumranet, разрабатывающую систему виртуализации KVM
  3. OpenNews: Создатели KVM выпустили коммерческое решение для виртуализации декстопов
  4. OpenNews: Интервью с разработчиком системы виртуализации KVM
Лицензия: CC-BY
Тип: К сведению
Короткая ссылка: https://opennet.ru/24625-redhat
Ключевые слова: redhat, spice, virtual, kvm
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (26) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (-), 00:11, 11/12/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Вот это дело.
    Ред хат как всегда молодцы
     
  • 1.2, pavlinux (ok), 00:11, 11/12/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • –5 +/
    > используется для организации работы тонких клиентов, приложения которых
    > выполняются на едином сервере виртуализации, на котором при помощи KVM может
    > выполняется множество Windows или Linux десктоп окружений.

    Так я (мы :))такую ещё 2006 годе написал(и)


    > имеющих доступ к локальным аудио и USB устройствам

    да-да-да, мы тоже у япошег стырили USB/IP http://usbip.sourceforge.net/

    > в SPICE рендеринг содержимого экрана производится на стороне клиента,

    Мы тоже умеем реверсинженерить SunRay протоколы

     
     
  • 2.11, Юниксоид (??), 11:17, 11/12/2009 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Где же можно посмотреть то, что Вы написали ? :-)
     
     
  • 3.20, pavlinux (ok), 17:06, 11/12/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >Где же можно посмотреть то, что Вы написали ? :-)

    Низя..., говорить-то про это не рекомендуется... :)

     
  • 2.18, anonymous (??), 13:20, 11/12/2009 [^] [^^] [^^^] [ответить]  
  • +/
    Подавайте в суд на нарушение авторских идей, мы вас поддержим.
     

  • 1.3, ПринцЧорнойТьмы (?), 00:19, 11/12/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Был еще симулятор электроцепей, который назывался тоже Spice.
     
  • 1.4, pavlinux (ok), 00:21, 11/12/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    >В отличие от таких протоколов как VNC (Virtual Network Computing),
    >ICA (Citrix Independent Computing Architecture) и RDP

    про VNC они молчат

    http://www.redhat.com/virtualization/rhev/desktop/spice/

    "SPICE is an adaptive remote rendering protocol used by
    Red Hat Enterprise Virtualization for Desktops to connect
    users to their virtual desktops. Unlike first-generation
    remote rendering protocols such as RDP and ICA, SPICE features
    a multi-tiered architecture that was designed to support
    today's multi-media desktop experience:"

     
  • 1.7, anonymous (??), 01:46, 11/12/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Анонимные аналитики-конспирологи считают, что теперь RHEL6 не за горами. Скорее всего это дело как раз тормозило процесс.

    Выходит, что по факту то самое преимущество X (супер пупер сетевая прозрачность) на деле не работает, коль приходится придумывать то же самое но другими способами. Печально. Я так верил в X, и OpenGL через него, и все так просто прозрачно эффективно... хнык.

     
     
  • 2.8, Slavaz (ok), 03:28, 11/12/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >Анонимные аналитики-конспирологи считают, что теперь RHEL6 не за горами. Скорее всего это
    >дело как раз тормозило процесс.
    >
    >Выходит, что по факту то самое преимущество X (супер пупер сетевая прозрачность)
    >на деле не работает, коль приходится придумывать то же самое но
    >другими способами. Печально. Я так верил в X, и OpenGL через
    >него, и все так просто прозрачно эффективно... хнык.

    Для X-сервера нужны тоже ресурсы,  причём в зависимости от запускаемой проги на стороне X-клиента потребление ресурсов может "скакать" и расти. А с простеньким X-сервером плюс VNC-вьювером потребление ресурсов(проц, память) на тонком клиенте всё время остается на примерно одном уровне. Наверное, проще проектировать клиентов (меньше RAM, не надо за сетевые свопы беспокоиться и т.д.).

     

  • 1.9, gennady (??), 10:46, 11/12/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Для сравнения терминал-сервер W2003  на 2*Xenon 2.0 2004G c 4G ОЗУ спокойно обслуживает 25-40 клиентов (операционисты банка) в зависимости от типа CPU. Декстоп на тянет i865 20-30 сессий.
    16Г дожно хватать на 150-200 клиентов минимум.
     
     
  • 2.10, аноним (?), 11:05, 11/12/2009 [^] [^^] [^^^] [ответить]  
  • +3 +/
    угу. Все так круто и надежно на самом Ксеноне! А Аргона или Неона нет у вас ?
     
  • 2.12, Юниксоид (??), 11:19, 11/12/2009 [^] [^^] [^^^] [ответить]  
  • +/
    25-40, из которых в каждый момент времени в idle 22-35 ? :-)

     
     
  • 3.13, gennady (??), 11:29, 11/12/2009 [^] [^^] [^^^] [ответить]  
  • +/
    25-40 активных сессий
     
     
  • 4.19, аноним (?), 16:05, 11/12/2009 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ну а у меня есть контрпример - 2х4 ядра Xeon, 16 Gb RAM, хранилище через FC. Все под windows 2003. И 8 юзеров завешивают сервер до неприличия. Один нюанс - на сервере разрабатывают ПО под .NET(WPF в основном).

    Какое отношение имеет это к теме топика ? Такое же, как и 25-40 одновременных сессий.

     
  • 2.14, anonymous (??), 11:53, 11/12/2009 [^] [^^] [^^^] [ответить]  
  • +/
    Ну операционисты банка и "типичные десктопные задачи" - этот разные вещи. Операционист банка может и по SSH работать с приложением на ncurses :-) Тогда сервер с 512Mb RAM сможет обслуживать 1000 клиентов.
     
  • 2.15, ананизмус (?), 12:03, 11/12/2009 [^] [^^] [^^^] [ответить]  
  • +/
    угу и они все сидят только в инете и в ворде простенький документ редактирует???
    видимо они у вас ничего на компе не делают.
     
     
  • 3.16, Slavaz (ok), 12:08, 11/12/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >угу и они все сидят только в инете и в ворде простенький
    >документ редактирует???
    >видимо они у вас ничего на компе не делают.

    Неужто они фотошопят, попутно что-то компилят и смотрят фильм?

    Чем занимаются операторы-операционисты в банках знаете? Запускают строго определённый набор ПО, часто чуть ли не под ДОС разработанный (консольные приложения не редкость). Шаг влево-вправо - и увольнение. Ибо бапки крутятся. Для них такие технологии - самое то.

     
  • 2.17, rm (??), 12:38, 11/12/2009 [^] [^^] [^^^] [ответить]  
  • +/
    вы путаете терминальные сессии и виртуализацию:) если что
     
  • 2.21, pavlinux (ok), 17:23, 11/12/2009 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Для сравнения терминал-сервер W2003  на 2*Xenon 2.0 2004G c 4G
    >ОЗУ спокойно обслуживает 25-40 клиентов (операционисты банка) в зависимости от типа
    >CPU. Декстоп на тянет i865 20-30 сессий.
    > 16Г дожно хватать на 150-200 клиентов минимум.

    40 клиентов породят [b]МИНИМУМ[/b] 20Mb/s * 40 = 3.2Gb трафик
    (20 - это ужо проверенное число, около 75% время держится такой трафик)
    При экране 1024x768x16 bit трафик будет 12.582.912 bit, при 40 юзеров 503.316.480
    И это только трафик на картинку экранов.

    Увеличим битность до 24 и  размер до 19" ~ 1280x1024
    Получим 1.258.291.200 ~ 1.2Gb/sec
    Опять же, только экран.
    Добавляем приложений, пользовательских данных, нагрузку от сервера приложений (АБС какая-нить),
    внешний трафик (если прорвётся :)), венда, сама ни хрена не делая, 15% жреёт проц и память...  

    Уже вижу дымящуюся стойку...

     
     
  • 3.23, pikador (?), 13:18, 12/12/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >[оверквотинг удален]
    >И это только трафик на картинку экранов.
    >
    >Увеличим битность до 24 и  размер до 19" ~ 1280x1024
    >Получим 1.258.291.200 ~ 1.2Gb/sec
    >Опять же, только экран.
    >Добавляем приложений, пользовательских данных, нагрузку от сервера приложений (АБС какая-нить),
    >внешний трафик (если прорвётся :)), венда, сама ни хрена не делая, 15%
    >жреёт проц и память...
    >
    >Уже вижу дымящуюся стойку...

    Что-то вы не то пишете, протокол RDP трафик использует весьма экономно, как раз для работы клиенту хватит 20-30 килобит. У меня 30 клиентов без особых проблем работали по каналу в 1 мегабит, и особых проблем со скоростью не было, даже с учетом того, что канал использовался не только для терминалов.

     
  • 3.24, Аноним (-), 13:21, 12/12/2009 [^] [^^] [^^^] [ответить]  
  • +/
    > 40 клиентов породят МИНИМУМ 20Mb/s * 40 = 3.2Gb трафик

    У операционистов банка?
    Сказочник!!!

    Такое может быть только если пытаешься смотреть видео или с какой нибудь 3D графикой.

    Работа на каналах для RDP от 512кбит/с для одной сессии через интернет для удаленного офиса (филиал) вполне компфортна. Конечно видео не посмотришь, но оно и не нужно, типичные же пользовательские проги типа почты, браузера, Сметы, 1С и т.п. вполне отзывчивы и быстры.

    Вот сейчас под FreeNX нормально работают по сети 100М/б не менее 15-20 пользователей без лагов. Типовые приложения firefox, openoffice и т.п.

    VNC да тормоз жуткий, но RDP и NomachineNX уже вполне сносны и на более низкоскоростных каналах.

     
     
  • 4.26, pavlinux (ok), 22:25, 13/12/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >> 40 клиентов породят МИНИМУМ 20Mb/s * 40 = 3.2Gb трафик
    >
    >У операционистов банка?
    >Сказочник!!!
    >
    >Такое может быть только если пытаешься смотреть видео или с какой нибудь
    >3D графикой.
    >

    Всё дико начинает висеть если один операционист переключается с одного
    приложения на другое, или просто сворачивает окно.
    А листание страниц в Консультанте?! Нажав PdDn трафик прыгает на 20Mb/s,
    самая веселуха с 10 до 13 когда все всё  делают.
    А как у же выше писали, сетевая печать убивает всё! А если операционисты генерят
    по 1 документу в 15 минут и их 20-30 челов. ....

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


     
  • 2.22, mma (?), 09:32, 12/12/2009 [^] [^^] [^^^] [ответить]  
  • +/
    C2D 3GHz/4Gb RAM/RAID1/w2003/1C - 30 клиентов
    2 x Xeon 4core 2.5GHz/8Gb RAM/RAID5 SAS 256mb/win2k3/1C - 25 клиентов максимум

    Не находите что все зависит от специфичности нагрузки а не от абстрактной ее составляющей?

     

  • 1.25, PAiN (?), 05:08, 13/12/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    блин народ вот RedHat допилет это и посмотрим что будет!


    А теперь посмотрим
        
         Автор я так понял что хотел сказать что ставится RHEV потом натягиваем 40-30 виртуальных машин (win & linux), пару танцев с бубном что бы работала с VLAN (вдруг вам понадобиться других пустить ) и и все это на 16 GB ! И пускаем это все на тонкие клиенты ! Я вам скажу что это очень хорошо так как виртулизация от MICRO такое не сможет !
    А если и сможет только для пасьянса!

     
     
  • 2.27, pavlinux (ok), 22:38, 13/12/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >[оверквотинг удален]
    >А теперь посмотрим
    >
    >     Автор я так понял что хотел сказать
    >что ставится RHEV потом натягиваем 40-30 виртуальных машин (win & linux),
    >пару танцев с бубном что бы работала с VLAN (вдруг вам
    >понадобиться других пустить ) и и все это на 16 GB
    >! И пускаем это все на тонкие клиенты ! Я вам
    >скажу что это очень хорошо так как виртулизация от MICRO такое
    >не сможет !
    > А если и сможет только для пасьянса!

    Я всегда рассчитываю как 1 ядро на 1 GHz и с 1Gb RAM = 1 VM + хостовая система.

    Тест прост - Это нормальное листание и прокрутка (scrolling) PDF страниц а Аcrobat Reader.

    То есть на Xeon 7450 или Opteron 2439 должно помещаться 12 машин, при 12-16 Gb RAM.
    Если используются одинаковые гости, то это очень уменьшает расход памяти.
    А если юзать Kernel Samepage Merging и kvm, то впихнуть 50 машин
    на 4 процесорнную мать с 4/6 ядерными процами как нефиг делать.
    (Ведь в новости не слова про Гигагерцы и количество процов и ядер?! :))

     

  • 1.28, artem (??), 11:03, 14/12/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    redhat - Роббин Гуды ;)
     

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



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

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