Нам интересно, как добавить ПОСЛЕДОВАТЕЛЬНЫЙ ПОРТ (COM2) в гостевой HPVM Windows 7 64 бит в гипервизоре xen server 6.5 без оболочки.
У нас есть несколько клиентов, подключающихся через RDP v8.1 (от Win7-64 к Win7-64) с двумя или более физическими ПОСЛЕДОВАТЕЛЬНЫМИ ПОРТАМИ.
Мы хотим обойти решение на основе физического разветвителя портов, потому что наша виртуальная серверная среда не может получать какие-либо физические периферийные устройства.
Обратите внимание, что у нашего хоста НЕТ физического последовательного порта, и мы спрашиваем, как / если XenServer 6.5 может добавить какое-либо последовательное устройство для подключения к любому из готовых к запуску драйверов виртуального последовательного порта.
Обратите внимание, что волшебство творят коммерческие инструменты.
Мы нашли быстрое и грязное решение, основанное на программном умножении портов, которое создает виртуальный порт, сопоставляя его с ip: port. Завершение процесса сразу после создания порта позволяет нам вызвать сервер терминалов и подключить удаленный и локальный ПОСЛЕДОВАТЕЛЬНЫЙ ПОРТ.
Угадайте, что если мы перезагрузим виртуальную машину, СЕРИЙНЫЙ ПОРТ отключится.
Как объявить новый ПОСЛЕДОВАТЕЛЬНЫЙ ПОРТ без IRQ свободным?
Мы не согласны с фокусом. Это проблема с гипервизором или с виртуальной машиной Windows?
Хост может напрямую связать один COM-порт виртуальной машины с физическим COM-портом HOST. Он действует как концентратор временной коммутации, моделируя непрерывное соединение (коммутацию цепей по последовательному протоколу).
Таким образом, данные виртуальной машины на COM-порте складываются в буфер, который ядро МОЖЕТ вставить в физический COM-порт хоста. Чтобы поддерживать равенство между коммутируемыми цепями, виртуальная машина может иметь столько COM-портов, сколько и хост.
Да, мы можем добавить много виртуальных COM-портов на виртуальную машину. Когда вы подключаете много физических периферийных устройств к RDP-клиентам, они не могут однозначно связать виртуальный COM-порт на виртуальной машине.
Это своего рода виртуальный COM-порт (на базе Windows) поверх виртуальной машины поверх реального хоста. Ядро не способно справиться с такой виртуальностью в виртуальности. Итак, мы должны действовать как «посредник», переписывая данные, чтобы привязать COM-порты виртуальных машин к одному виртуальному (уровень Citrix domU).
Итак, ситуация: одна реальная рабочая станция, множество физически связанных периферийных устройств через реальные COM-порты, через RDP на виртуализированном хосте RDS, работающем поверх Xen, размещенном на хосте только с ОДНИМ портом COM.
Итак, результат: только последнее "коммутируемое" и связанное через RDP физическое периферийное устройство клиента может связать ядро виртуальной машины. Все охтеры сбрасываются молча.
Итак, факт: мы не можем симулировать COM-порт на хосте и связать его через Intel VT. Это ограничение на основе ядра.