Релиз QEMU 2.6.0

чем тебя pc (i440fx) не устраивает, тем более для винды?

Первичный вопрос был «Что есть в Hyper-V чего нет в VBox?». VMWare тут какбы не при чём.

Ответ: это две разные системы виртуализации.

Чёта мы ходим по кругу:

VirtualBox лучше Hyper-V по некоторым критериям хотя первый второму в подмётки не годится по другим критериям

По каким критериям VirtualBox не годится Hyper-V в подмётки?

недавно в тайване на него одно производство перевёл, и там интенсивно тестировали наработку на отказ.

Солярис? Какой версии?

Разработчик - наш

Он не с Бреста?

Я пробовал заводить эти драйвера для ВМ — не взлетела. Пришлось Hipster использовать =(

По каким критериям VirtualBox не годится Hyper-V в подмётки?

Вопросом на вопрос: Где в VBox где-то есть живая миграция с хоста на хост? Если где-то не сам гипервизор а в составе системы виртуализации на основе VBox это крутится ткни носом, я упорин не принимаю признаю что VBox круче. Слежу за новостями и глядя сколько каждый раз закрывают «проблемы» и какие боюсь к нему подходить. Опять-же покажи где оно в продакшне. Я не слышал. Для меня видимой частье явл. наличие дистра для десктопов и возможность поставить из реп. Против QEMU/KVM кстати ничего не имею но нет времени на миграцию/эксперименты а так-бы давно свинтил с Hyper-V, дубовый он, но ЧСХ работает.

Ты какой-то трудный. От тебя два дня просят простой список вида:

1. Функциональность, отсутствующая в VirtualBox:
а)
б)
в)
2. Функциональность, отсутствующая в Hyper-V:
а)
б)
в)

Где в VBox где-то есть живая миграция с хоста на хост?

Опять-же покажи где оно в продакшне

VB совсем для других целей и применения нежели QEMU/KVM или Hyper-V, по каким критериям ты их сравниваешь и зачем я вообще не понимаю. Какая «живая миграция с хоста на хост», какой «продакшн» применительно к VB, ты о чём вообще?

тут люди упорина попили и чё-то требуют в контексте «что есть в хайпер-ви чего нет в Вбокс», если хочется сравнений гугол в помощь и пусть сравнивают. СОГЛАСЕН и выше писал что НЕТ смысла сравнивать ибо есть критерий СФЕРА ПРИМЕНЕНИЯ. блжд..

Восьмёрка. Был ещё проект по переводу другой линии производства, под десяткой, но там клиент всё-таки выбрал закрытое решение. Ну, флаг им лет через 10, чо.

Эээ... ты хочешь сказать, что на Qemu работает Solaris, который управляет производством, т.е. буквально рулит железом? O_O Или там АСУТП верхнего уровня или даже АСУП?

Именно, рулит железом. Ну, не прямо моторчиками, а это то, что видит оператор. Моторчиками рулит какая-то платка, подключеная по Ethernet. На эти линии производства гарантия 25 лет, старые спарки начали потихоньку сыпаться, а пользователи готовы продлить гарантию ещё лет на 5-10.

Аахренеть. И оно успевает в режиме программной эмуляции SPARC?

У тех спарков была производительность...

Понятно, что это другое поколение, но если там исполнялся Solaris 8 - это были не самые медленные SPARC.

По прежнему от слова «нинужно».

не самые медленные SPARC

А такие производились? ;)

KVM использует QEMU, что сравнить хотите?

оно лучше обоих. т.к. mainstream и открытое

можно попробовать прописать SATA контроллер или IDE мы проходили - получалось физические машины затаскивать вообще ничего не меняя в них.

Понятно, что это другое поколение, но если там исполнялся Solaris 8 - это были не самые медленные SPARC.

Закон Мура на моей стороне. :-) Ну, и всё-таки там не совсем ванильный qemu. Хотя, наверно, даже и ванильный справился бы в конечном итоге.

Вот что интересно: как дело спросишь - порой сутками ответа не дождёшься, а как тупой вброс сделаешь - ответы, как из рога изобилия!

Годно, нужно будет обновиться.

эмуляция Raspberry Pi 2

тоже интересно. можно будет опробовать потянет ли оно требуемые задачи

Если не используется аппаратное декодирование видео, на любом современном компе qemu будет существенно быстрее чем RPi.

Ага. Тоесть узнать, справится ли реальная железка с задачей нельзя? ps видео там вообще не планируется

Тоесть узнать, справится ли реальная железка с задачей нельзя?

С помошью qemu - никак. QEMU не эмулирует устроства потактно, как например, mess/mame. Даже, в архитектурах, для которых реализован throttling, можно только указать % от максимальной производительности, которая зависит от скорости хоста, на котором QEMU запущен.

Скорость эмулируемой железки может быть как намного быстрее, так и намного медленнее оригинала. И даже то и другое одновременно: какие-то операции могут быть быстрее, какие-то медленнее.

Точно. Вспомнил какой-то старый эмулятор первой плойки — там требовался процессор «строго определенной» частоты и у меня он запускаться уже отказывался.
Тем не менее, раз запилили эмуляцию данной железки, значит кому-то оно нужно. Интересно, а состояние gpio там отображается или как-то еще можно взаимодействовать с ним?

поддержка безмониторных конфигурации с OpenGL через Virgil/virtio-gpu в клиенте Spice

Что-то я не пойму как это запускать. Qemu 2.6.0, в мане написано, что опция -spice поддерживает параметр gl=on, но qemu ругается на строку:

$ qemu-kvm -m 4096 -drive file=/media/storage/virt/fedora.qcow2,if=virtio -net bridge -net nic,model=virtio -vga virtio -spice unix,disable-ticketing,addr=/tmp/vm.sock,gl=on
qemu-system-x86_64: -spice unix,disable-ticketing,addr=/tmp/vm.sock,gl=on: Invalid parameter 'gl'

-spice unix,disable-ticketing,addr=/tmp/vm.sock -display none,gl=on запускается, но virgl в вм не работает. С -display sdl,gl=on всё работает нормально. ЧЯДНТ?

Сравнение теплого с мягким будет гораздо интереснее.

Тебе даже дали «сохранить лисо», пусть и лишь в твоём воображении. Не узнаю ЛОР.

Я не нумизмат, но мне тоже интересно. Все-таки хотелось бы уточнения «Именно, рулит железом» или «ИМЕННО, рулит железом». Т.е. все-таки сама программа руления исполняется на SPARC или стоит контроллер который реально рулит моторчиками и уже он подключен к SPARC где оператор может корректировать работу отдавая команды?

сама программа руления исполняется на SPARC

Смотря что понимать под «рулением». На SPARC исполняется программа, которая формирует управляющий пакет, который посылается на исполняющее устройство по Ethernet.

Смотря что понимать под «рулением». На SPARC исполняется программа, которая формирует управляющий пакет, который посылается на исполняющее устройство по Ethernet.

Вот именно и интересует само «устройство» это конечные «моторчики» или самостоятельные контроллеры которые и так рулят режимами и только по запросу изменяют «состояние». Если второй вариант то ничего сверх естественного нет, хоть виндой рули.

Вот именно и интересует само «устройство» это конечные «моторчики» или самостоятельные контроллеры которые и так рулят режимами и только по запросу изменяют «состояние»

Моторчики управляются электрическими сигналами. Понятно, что эти сигналы выдает какой-то контроллер - судя по наличию Etherneеt, довольно умный.

Если второй вариант то ничего сверх естественного нет, хоть виндой рули.

Гг. Всё дело в директивных сроках, а не в архитектуре. Принципиально Ethernet ничем не отличается от GPIO.

Моторчики управляются электрическими сигналами. Понятно, что эти сигналы выдает какой-то контроллер - судя по наличию Etherneеt, довольно умный.

Вот именно к фразе «довольно умный» я и веду. Насколько умный?
Задам вопрос проще, без этого SPARC сам тех процесс работать будет или нет?
Я знаю о местах где спарки выполняли роль управления менее умными контролерами, т.е. чисто самостоятельная железка. Однако alt-x написал «а это то, что видит оператор. » поэтому и хочется понять о чем речь. А так же мне слабо вериться в вариант работы спарка под сабжем в RT.

Вот именно к фразе «довольно умный» я и веду. Насколько умный?

А в чем мерять? Если в задержках, то я вижу на потолке цифры в десятки миллисекунд. Но миллисекунды плохая метрика для умности контроллера.

Задам вопрос проще, без этого SPARC сам тех процесс работать будет или нет?

Я вижу на потолке категоричное «Нет».

А так же мне слабо вериться в вариант работы спарка под сабжем в RT.

ТС вполне определенно сказал «там не ваниль», так что почему бы и нет.

Принципиально Ethernet ничем не отличается от GPIO.

«Принципиально» через ethernet и 485-м rs на другом конце страны рулить можно. Вопрос в скорости «руления», если нужен rt как-то фигово получается «рулить» :)

Ну я и говорю, что вопрос в величине допустимых временных задержек. Если это десятки миллисекунд - не вижу ничего невероятного.

ТС вполне определенно сказал «там не ваниль», так что почему бы и нет.

Ок. Предлагаю все-таки дождаться ответа от alt-x, а то наша переписка больше рентв попахивает.

Ну я и говорю, что вопрос в величине допустимых временных задержек. Если это десятки миллисекунд - не вижу ничего невероятного.

ЗЫ Открою вам «большую тайну», «десятки миллисекунд» даже в обычном десктопном клиент-серверном приложении работающем с одной субд (без разницы блокировщик или версионник) уже «очень много». Это только «newbaby от програмизма» думают что не может быть случая нажатия одной и тойже кнопки у трех пользователей программы в течении нескольких милисекунд.

Открою вам «большую тайну»

Закрой обратно.

уже «очень много»

Очень много - это когда в директивный срок не вписался.

нажатия одной и тойже кнопки у трех пользователей программы в течении нескольких милисекунд.

Картина маслом - тайваньские инженеры тайно подключают к сети новых пользователей^Wстанки.

Очень много - это когда в директивный срок не вписался.

Не стебайтесь... а да, в предыдущем посте смайл забыл поставить, моя вина, извините действительно воспринимается в «штыки».
А так все что описал правда жизни, виденная не раз, к АСУТП не имеющая отношения.

Задам вопрос проще, без этого SPARC сам тех процесс работать будет или нет?

Не будет.

Вопрос в скорости «руления»

Ну, учитывая что хватает 10Мбитного Ethernetа, сверхсветовой скорости там не требуется.

Станкам порядка 20 лет (десять двухлетий). Закон Мура говорит, что компы стали за это время примерно в 2^10 = 1024 раз быстрее. Понятно, что закон Мура в таком виде перестал действовать несколько лет назад, но, всё равно получается что текущие компы - в сотни раз быстрее тогдашних. Как-то так.

ТС вполне определенно сказал «там не ваниль», так что почему бы и нет.

Да, в общем-то, сейчас и ваниль хороша. И это ж не первый проект мой на эту тему. Не помню, уже, хвастался или нет, как я пару лет назад трёхтысячетонный океанский корабль под QEMU перевёл. Если не хвастался, вот: http://tyom.blogspot.de/2013/04/using-qemu-to-navigate-3000-tons-ship.html .

Тогда, да, реально впечатляет!!! Очень не слабая история успеха!!!

Ну, учитывая что хватает 10Мбитного Ethernetа, сверхсветовой скорости там не требуется.

Тут я имел ввиду не «обьем» передаваемых данных а именно скорость реакции на события. Все-таки спарк в сабже ну никак на RT не тянет. Но раз работает значит такого и не требуется. Все равно хороший пример!!!

Почитай мои посты на тему Xen, KVM и т.п., и всё сам поймёшь.

Круто!