![](/sites/default/files/social_buttons/ohloh.png)
![](/sites/default/files/social_buttons/vimeo.png)
![](/sites/default/files/social_buttons/github.png)
![](/sites/default/files/gplus.png)
![](/sites/default/files/feed.png)
![](/sites/default/files/social_buttons/linkedin.png)
![](/sites/default/files/social_buttons/facebook.png)
![](/sites/default/files/social_buttons/twitter.png)
![](/sites/default/files/social_buttons/vkontakte.png)
![](/sites/default/files/social_buttons/youtube.png)
Приглашаем на встречу разработчиков Linux-контейнеров — мероприятие сообщества OpenVZ, которое пройдёт 19 сентября в московском офисе Яндекса. Оно пригодится всем, кто интересуется применением контейнеров и контейнерной виртуализацией.
На встрече вы узнаете про плюсы и минусы живой миграции контейнеров, библиотеку LibCT, новый менеджер памяти в OpenVZ. Докладчики расскажут о решении проблемы фрагментации виртуальных дисков, применении контейнерных технологий в DevOps-процессах и особенностях использования OpenVZ в инфраструктуре крупного хостинг-провайдера.
Участие во встрече бесплатное, однако нужно зарегистрироваться.
Программа:
Как проехать:
- 11:00 Регистрация
- 11:30 Живая миграция контейнеров: плюсы, минусы, подводные камни. Павел Емельянов, Odin
- 12:00 Управление памятью контейнеров в проекте OpenVZ. Владимир Давыдов, Odin
- 12:30 Перерыв
- 12:40 LibCT и контейнеры на уровне приложений. Андрей Вагин, Odin
- 13:10 Использование контейнерных технологий в DevOps. Дмитрий Лазаренко, Jelastic
- 13:40 Перерыв
- 14:30 Опыт использования виртуальных контейнеров в работе сервис-провайдера. Константин Анисимов, Русоникс
- 15:00 CRIU: ускорение запуска PHP в CloudLinux OS. Руслан Куприев, CloudLinux
- 15:30 Перерыв
- 15:40 Развёртывание приложений Docker в контейнерах Virtuozzo. Павел Тихомиров, Odin
- 16:10 Проблема фрагментации виртуальных дисков и способы её решения. Дмитрий Монахов, Odin
- 16:40 Закрытие
Москва. Ул. Льва Толстого, 16. Конференц-зал «Экстрополис»
Наиболее популярной ОС с открытым исходным кодом является продукт американской компании Red Hat. На его базе функционирует оборудование 25 ФГИС. Доли других ОС приведены в таблице.
Разновидности Linux, используемые в ФГИС
Число ФГИС Red Hat 25 Debian 15 CentOS 15 Ubuntu 11 Fedora 8 Mandriva 7 SUSE 5 МСВС 2 Alt Linux 1 Oracle Enterprise Linux 1 Данные: аналитический центр TAdviser Report, август 2015
Самым популярным дистрибутивом Unix, согласно исследованию, является FreeBSD. Доли остальных разновидностей приведены в таблице.
Разновидности Unix, используемые в ФГИС
Число ФГИС FreeBSD 13 Oracle Solaris 8 IBM AIX 7 HP-UX 2 Циркон 1 Данные: аналитический центр TAdviser Report, август 2015
На базе российских дистрибутивов Linux - МСВС и Alt Linux - работают серверы только трех ФГИС.
Проброс USB в виртуалку по сети средствами usbredir и qemuСистемное администрирование*, Виртуализация*, Open source*, *nix*
На сегодняшний день существет довольно много способов пробросить USB-устройство на другой компьютер или виртуалку по сети.
Из наиболее популярных — железячные такие как AnywhereUSB и чисто програмные продукты, из тех что я попробовал сам: USB Redirector и USB/IP.
Я бы хотел рассказать вам еще об одном интересном способе, который работает непосредственно с эмулятором qemu.
Он так же является частью проекта spice, официально поддерживаемым RedHat.
usbredir, это открытый протокол для проброса usb-устройств по tcp на удаленный виртуальный сервер, разработанный при поддержке RedHat в рамках проекта spice. Но как оказалось им можно вполне успешно пользоваться и без spice. В роли сервера выступает usbredirserver, который шарит usb-устройство на определенный порт, а в качестве клиента сам qemu, который эмулирует подключение экспортированного usb-устройства в определенный usb-контроллер вашей виртуальной машины. Благодаря такому подходу в качестве гостевой системы может использоваться абсолютно любая ОС, так как она даже не знает, что устройство является проброшенным удаленно, а вся логика ложится на qemu.
Для начала несколько слов о вышеперчисленных решениях
- AnywhereUSB — довольно неплохое решение, но дорогое, и имеет неприятние глюки, например бывает если расшаренная флешка отваливается, то переподключить ее обратно можно только физически вынув и вставив ее.
- USB/IP — OpenSource проект. Вроде как был заброшен. По факту глючит довольно сильно. При разрыве соединения, машина частенько уходит в полнейший freezee, а windows показывает BSOD
- USB Redirector — Замечательная софтина. Для расшаривания устройств с linux на linux бесплатна, во всех остальных случаях уже стоит денег, не так много как AnywhereUSB, но и не бесплатно как хотелось бы :)
Как видно есть из чего выбрать, но давайте же наконец попробуем еще один способ — usbredir?
Настройка виртуальной машины
Для того что бы было куда подключать экспортированные устройства, на виртуальной машине нужно создать необходимые usb-контроллеры:
- uhci — для USB1.0
- ehci — для USB2.0
- xhci — для USB3.0
Для qemu (без libvirt)
Скачайте конфиг ehci-uhci.cfg, положите его в /etc/qemu/
$ curl http://cgit.freedesktop.org/spice/qemu/plain/docs/ich9-ehci-uhci.cfg --create-dirs -o /etc/qemu/ehci-uhci.cfg
И добавьте следующие опции в команду запуска виртуальной машины:
-readconfig /etc/qemu/ich9-ehci-uhci.cfg -chardev spicevmc,name=usbredir,id=usbredirchardev1 -device usb-redir,chardev=usbredirchardev1,id=usbredirdev1,debug=3 -chardev spicevmc,name=usbredir,id=usbredirchardev2 -device usb-redir,chardev=usbredirchardev2,id=usbredirdev2,debug=3 -chardev spicevmc,name=usbredir,id=usbredirchardev3 -device usb-redir,chardev=usbredirchardev3,id=usbredirdev3,debug=3
Для libvirt
Можно использовать такой конфиг.
В исходном файле конфигурации виртуальной машины в узле <devices> удаляем все USB контроллеры и добавляем следущий блок:
<controller type='usb' index='0' model='ich9-ehci1'> <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x7'/> </controller> <controller type='usb' index='0' model='ich9-uhci1'> <master startport='0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0' multifunction='on'/> </controller> <controller type='usb' index='0' model='ich9-uhci2'> <master startport='2'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x1'/> </controller> <controller type='usb' index='0' model='ich9-uhci3'> <master startport='4'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x2'/> </controller> <redirdev bus='usb' type='spicevmc'> <address type='usb' bus='0' port='3'/> </redirdev> <redirdev bus='usb' type='spicevmc'> <address type='usb' bus='0' port='4'/> </redirdev> <redirdev bus='usb' type='spicevmc'> <address type='usb' bus='0' port='5'/> </redirdev> <redirdev bus='usb' type='spicevmc'> <address type='usb' bus='0' port='6'/> </redirdev>
Но у меня он почему-то не заработал, и я решил пойти другим путем, а именно явно указть libvirt с какими опциями запускать qemu:
Этот блок рамещается перед тегом </domain>:
Не забудьте так же скачать конфиг ehci-uhci.cfg, и сохранить его в /etc/qemu/ как в случае с qemu без libvirt<qemu:commandline> <qemu:arg value="-readconfig"/> <qemu:arg value="/etc/qemu/ich9-ehci-uhci.cfg"/> <qemu:arg value="-chardev"/> <qemu:arg value="spicevmc,name=usbredir,id=usbredirchardev1"/> <qemu:arg value="-device"/> <qemu:arg value="usb-redir,chardev=usbredirchardev1,id=usbredirdev1,bus=ehci.0,debug=3"/> <qemu:arg value="-chardev"/> <qemu:arg value="spicevmc,name=usbredir,id=usbredirchardev2"/> <qemu:arg value="-device"/> <qemu:arg value="usb-redir,chardev=usbredirchardev2,id=usbredirdev2,bus=ehci.0,debug=3"/> <qemu:arg value="-chardev"/> <qemu:arg value="spicevmc,name=usbredir,id=usbredirchardev3"/> <qemu:arg value="-device"/> <qemu:arg value="usb-redir,chardev=usbredirchardev3,id=usbredirdev3,bus=ehci.0,debug=3"/> </qemu:commandline>
Кстати, после данной настройки, если вы используете spice, станет возможен проброс usb-устройств с клиента spice на сервер.
Заводим виртуалку, теперь все готово для осуществления проброса.
Запуск сервера
Пакет usbredirserver можно найти в стандартных репозиториях практически во всех популярных дистрибутивах linux.
Вставляем флешку в компьютер, смотрим вывод usb-устройств:
$ lsusb ... Bus 003 Device 011: ID 125f:c82a A-DATA Technology Co., Ltd. ...
Видим что пара vendorid:prodid равна 125f:c82a, а ядро определило флешке 003-001 usbbus-usbaddr соотвественно.
Теперь давайте расшарим ее на 4000 порт:
# Используя пару vendorid:prodid $ usbredirserver -p 4000 125f:c82a # Используя пару usbbus-usbaddr $ usbredirserver -p 4000 003-011
Подключение устройства к виртуальной машине
Заходим на гипервизор и в qemu-monitor нашей машины выполняем следующие команды:
# Добавляем наше устройство chardev-add socket,id=usbredirchardev1,port=4000,host=192.168.1.123 # Подключем его в ehci контроллер (USB-2.0) device_add usb-redir,chardev=usbredirchardev1,id=usbredirdev1,bus=ehci.0,debug=4
Что бы отключить флешку достаточно такой команды:
device_del usbredirdev1
Если у вас libvirt, то команды в qemu-monitor можно отправить следующим образом:
$ virsh qemu-monitor-command --hmp one-73 'chardev-add socket,id=usbredirchardev1,port=4000,host=192.168.1.123' $ virsh qemu-monitor-command --hmp one-73 'device_add usb-redir,chardev=usbredirchardev1,id=usbredirdev1,bus=ehci.0,debug=4' $ virsh qemu-monitor-command --hmp one-73 'device_del usbredirdev1'
На этом все, после данных шагов ваша ВМ увидит вашу флешку и сможет с ней нативно работать.
Если устройств много и все они одинаковые
Вот тут появилась интересная задачка, как пробросить несколько одинаковых девайсов на разные ВМ?
При этом, стоит отметить, все устройства имеют одинаковую пару vendorid:prodid, а пара usbbus-usbaddr совсем не постоянна, стоит только вынуть и вставить устройство, так оно сразу поменяет свой usbaddr.
Для себя я решил ее при помощи udev, и небольшого скрипта.
Кстати если вы не совсем понимаете как работает udev, на Debian Wiki есть классная статья о udev
И так приступим:
Для начала узнаем серийник нашего устройства, по которому и будем идентифицировать его в udev:
$ udevadm info -a -n /dev/bus/usb/003/011 | grep '{serial}' ATTR{serial}=="11C130317234004B" ATTRS{serial}=="0000:00:14.0"
Теперь создадаим файл /etc/udev/rules.d/99-usb-serial.rules и запишем в него следующее правило:
SUBSYSTEM=="usb", ATTRS{idVendor}=="125f", ATTRS{idProduct}=="c82a", ATTR{serial}=="11C130317234004B", SYMLINK+="usbdevices/token1"
Перезагрузим udev-правила:
$ udevadm control --reload-rules
Теперь, при подключении нашей флешки, в /dev/usbdevices/token1 на нее появится симлинк.
Я написал небольшой скрипт, который использует этот симлинк, для того что бы узнать настоящую пару usbbus-usbaddr устройства и расшарить его на нужный порт
usbredirserver-by-symlink.sh
#!/bin/bash keys="${@:1:${#}-1}" usblink="${@: -1}" if [ -L $usblink ] && [ $# != 0 ]; then usbbus=`udevadm info -a -n $usblink | awk -F== '/ATTR{busnum}/ { gsub(/"/,"",$2);print $2 }'` usbaddr=`udevadm info -a -n $usblink | awk -F== '/ATTR{devnum}/ { gsub(/"/,"",$2);print $2 }'` if [ "$usbbus" != "" ] && [ "$usbaddr" != "" ]; then usbredirserver $keys $usbbus-$usbaddr else echo "This is not usb device" exit 1 fi else echo "Usage: usbredirserver-by-symlink.sh [-p|--port <port>] [-v|--verbose <0-5>] /dev/usbdevice" exit 1 fi
К сожалению от смены пары usbbus-usbaddr после расшаривания устройства этот скрипт не спасет, так как usbredirserver не отваливается, если устройство вынуть или если такое устройство вообще не существует. Но он облегчит путь и поможет не запутаться при расшаривании нужного устройства на нужные ВМ.
В дальнейшем его можно будет использовать, для написания следующего скрипта, который будет мониторить подключение/отключение устройств, расшаривать нужные и автоматически подключать/отключать их на удаленной ВМ.
Источники:
umvirt.ru/node/82
opennebula.org/opennebula-for-virtual-desktops
opennet.ru/opennews/art.shtml?num=30773
lists.gnu.org/archive/html/qemu-devel/2013-07/msg05244.html
Bastien Nocera рассказал о своем опыте запуска Linux на дешевом Windows-планшете и заодно предложил новый способ работы GNOME с новым оборудованием - чтобы было так просто, как и с Android.
Половину своего выступления Bastien рассказывал то, как вообще можно сферически запустить сферический Linux (а потом и GNOME) на новом сферическом устройстве. А вот под конец, он вернулся к началу и изложил события ровно в том порядке, в котором они произошли в реальности (с гораздо меньшим успехом). Но, как он подчеркнул, более успешная версия событий вполне достижима, если внести немного изменений в GNOME.
История началась, когда Bastien купил дешевый китаепланшет, и решил поставить туда операционную систему GNOME вместо Windows 8. Главной проблемой был неработающий WiFi. В планшете был чип от Realtek, и Bastien даже сумел получить к нему исходники от компании, но они были в ужасном состоянии.
Скорее всего исходники были от драйвера для Android, но с мэйнстримовым Linux-ядром они не работали. Покопавшись в исходниках он обнаружил, что они забиты бесполезным мусором - тестами, кодом для препродакшен-версий оборудования, и т.д. В драйвере был даже какой-то код для USB, т.к. wifi был физически подключен к материнской плате через USB. В конечном итоге, с помощью других программистов, среди которых были и наши коллеги, он сумел выкинуть лишнее, и кодовая база уменьшилась в 20 раз.
Затем они привели его в состоянии пригодности для работы со стандартным ядром. Это заняло время, но все заработало, и после того, как получившийся код был выложен на GitHub on начал работу над следующей задачей. Следующим он добился работоспособности USB On-The-Go, что позволило подключиться к планшету через USB. Это, в свою очередь, позволило ему использовать Android Debug Bridge (adb), чтобы контролировать и мониторить процесс загрузки. Для этого пришлось поправить adb-демон, чтобы он работал с glibc и systemd, вместо Bionic и init из Android. Пропатченный adb он также выложил на GitHub.
Тут уже он настроил "EFI mixed mode" (загрузка 64-битного ядра 32-битным firmware), а позже он заменил загрузчик на GRUB, настроил Secure Boot shim, и запустил инсталлятор Fedora, чтобы установить полноценную 64-битную Linux-систему. ADB позволяет загружать пакеты на планшет, так что с поддержкой его в GNOME, разработчики могли бы создавать приложения xdg-app с помощью GNOME Builder на рабочих машинах, загружать их по USB на планшеты и тут же тестировать. Никаких эмуляторов, симуляторов, и не нужно было бы.
Тут то Nocera и остановился, чтобы сообщить, что лишь половина этого всего случилась в реальности. Ну, пока так. Действительно, ему удалось запустить WiFi с помощью Larry Finger. И его работа над ADB и EFI mixed mode тоже существует, хотя не все патчи готовы к включению в апстрим.
То, что он рассказывал, это то, что бы он хотел от GNOME в ближайшее время, и что ему хотелось бы обсудить. Все кусочки уже в наличии - xdg-app может создавать образы, которые, как и apk-файлы для Android, разработчик мог бы попробовать установить и потестировать. GNOME Builder хорошо бы, чтобы умел создавать пакеты xdg-app, и было бы здорово интегрировать его с adb.
Тут есть и другие проблемы, некоторые совсем не относятся к GNOME. Windows 8 не поддерживает USB On-The-Go, и поэтому даже если system-on-chip, используемый в планшете, поддерживает USB OTG, производитель может не присоединить его к материнской плате. Одной из альтернатив был бы кабель USB host-to-host - они дешевы, но потребуется некоторая работа, чтобы они надежно работали c Linux-десктопами. Внутри таких коннекторов используются дешевые сетевые адаптеры USB, между которым находится Ethernet-хаб, поэтому поддержка их потребует разработки драйверов.
Гораздо большей проблемой может стать то, что EFI mixed mode пока не полностью подерживается в Linux. Действительно, уже можно загрузить 64-битный Linux на 32-битном UEFI, но когда драйверы начинают обращаться к UEFI, тогда начинаются проблемы. Ну и проблема еще в том, что дешевые планшеты меняются очень быстро, и поддерживать большое количество моделей будет непросто. Но если на планшет можно установить старую версию Windows, то скорее всего легко получится запустить и Linux.
Nocera закончил выступление объявив, что претензии не принимаются. Он сказал, что сожалеет, что ему пришлось приврать в первой части доклада, когда он рассказывал про идеализированный сценарий, скрыв, что еще необходимо много работы. Но именно такая поддержка оборудования, это именно то, что нужно для распространения GNOME. Мобильные устройства никуда не уйдут, и т.к. у Android есть захватывающая история о том, как каждый желающий может подключить UBS-кабель, и начать разрабатывать ПО, которое можно сразу же запустить на любом планшете или телефоне, то GNOME стоило бы обеспечить такой же уровень поддержки.