О чём пойдёт речь

В первой части мы разобрали архитектуру SPICE: каналы, TCP-only, image-based подход. Во второй — Display Channel: режимы Image и Stream, кодеки, реальность 4K. Осталась тема, которую часто недооценивают при выборе VDI-решения.

Input Channel. Cursor Channel. Round-trip latency.

Про картинку говорят все. Битрейт, кодеки, разрешение — это то, что легко измерить и показать на слайде. А вот ощущение от работы с удалённым рабочим столом измерить сложнее. И именно оно определяет, приживётся VDI в компании или станет источником постоянных жалоб.

Я видел внедрения, где картинка была отличная, а пользователи всё равно ненавидели систему. И видел обратное — откровенно «мыльное» изображение, но люди работали и не жаловались. Разница почти всегда была в отклике на ввод.

Сначала про боль

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

История, которая повторяется

Компания внедряет VDI. Пилот прошёл успешно — на тестовой группе из пяти человек всё летало. Закупили лицензии (или, в случае SPICE, сэкономили на них), раскатили на 200 пользователей, отрапортовали об успехе.

Через месяц начинается.

Бухгалтерия: «Excel тормозит». IT проверяет — Excel работает, fps нормальный, bandwidth достаточно. Но бухгалтер настаивает: «Я двадцать лет работаю в Excel, я знаю, когда он тормозит».

Сисадмин настраивает Windows Server. Кликает по формам, вводит IP-адреса, быстро печатает не глядя на экран — он же знает, что набирает. А потом смотрит — и половина цифр не там. Потому что курсор не успел встать в нужное поле, когда начался ввод. Особое развлечение — ввод ��ароля. Вслепую, со спецсимволами, с раскладкой которая может быть не той. «Неверный пароль». Ещё раз. «Неверный пароль». Учётка заблокирована. Классика.

Call-центр: операторы вводят данные клиента во время звонка. Клиент диктует номер телефона — оператор печатает. Цифры появляются с задержкой. Приходится останавливаться, ждать, проверять. «Повторите, пожалуйста». Время обработки звонка растёт на 10-15 секунд. На сотнях звонков в день — это часы. KPI падает, руководство требует объяснений.

Руководство: «Мы заплатили за современное решение, а люди жалуются». IT разводит руками — метрики в норме.

Почему метрики врут

Стандартные метрики VDI — bandwidth, fps, CPU utilization — не ловят проблему отклика. Можно иметь стабильные 60 fps и при этом 200 мс round-trip latency. На графиках всё зелёное, а пользователь страдает.

Это как измерять качество телефонного разговора по громкости звука. Громко — но с эхом в полсекунды. Формально всё в порядке, а разговаривать невозможно.

Почему отклик важнее картинки

Человеческое восприятие устроено несимметрично. И это не философия — это физиология, которая напрямую влияет на то, как люди воспринимают VDI.

К качеству картинки адаптируются

Мы десятилетиями смотрели VHS, потом DVD, потом мутные стримы на раннем YouTube. Мозг умеет достраивать детали, игнорировать артефакты сжатия, привыкать к «мылу». Через пятнадцать минут работы в VDI с неидеальной картинкой пользователь перестаёт это замечать — если только не начинает специально приглядываться.

У меня был случай: настроили SPICE с MJPEG (да, тот самый, из 2009 года), качество было так себе. Пользователи поворчали неделю и привыкли. Через месяц никто не вспоминал. А это было серьёзное подразделение федеральной структуры — сотни людей, огромный документооборот, критичные сроки. Картинка «не очень» — работают. Задержка ввода — бунт.

К задержке ввода не адаптируются

А вот с задержкой так не работает.

Когда вы двигаете мышь, вы ожидаете, что курсор последует за рукой. Это не сознательное ожидание — это рефлекс. Зрительно-моторная координация формируется в первые годы жизни и работает на уровне, который сознанием не контролируется.

Задержка в 50 мс — незаметна большинству людей. 100 мс — уже ощущается как «что-то не так», хотя человек не может сформулировать, что именно. 150 мс — «тормозит». 200 мс — «невозможно работать, верните нормальный компьютер».

Причём это не вопрос привычки. Геймеры, которые годами играют с задержкой 50-80 мс, всё равно чувствуют разницу с локальным откликом. Они адаптируют стратегию игры, но дискомфорт никуда не девается.

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

Похоже на укус комара — вроде мелочь, но зудит и мешает сосредоточиться. Один укус переживёшь. Десять за день — уже выматывает. Сотня микрозадержек за рабочий день — и человек уходит домой с ощущением, что весь день боролся с системой.

Субъективно, но показательно

Я пробовал работать через VDI с разными значениями искусственной задержки (добавлял через tc qdisc на тестовом стенде). Мои ощущения:

  • 30 мс — не отличаю от локального

  • 50 мс — если специально прислушиваться, можно заметить

  • 80 мс — заметно, но терпимо для обычной работы

  • 120 мс — раздражает, особенно при работе с мышью

  • 150 мс — хочется закрыть сессию

  • 200 мс — физически некомфортно, начинает укачивать

Это субъективно и зависит от человека. Кто-то чувствительнее, кто-то менее. Но порядок величин примерно такой.

Round-trip latency: откуда берётся задержка

Round-trip latency (RTL) — время полного цикла от действия пользователя до визуального отклика. Нажал клавишу — увидел букву. Сдвинул мышь — увидел движение курсора.

Анатомия одного нажатия клавиши

Разберём, что происходит, когда пользователь нажимает клавишу «A» в текстовом редакторе:

1. Палец нажимает клавишу
   ↓ [USB polling: 1-8 мс, зависит от клавиатуры]
   
2. ОС клиента получает событие
   ↓ [обработка в клиенте: 1-3 мс]
   
3. remote-viewer формирует SPICE_MSGC_INPUTS_KEY_DOWN
   ↓ [сеть: RTT/2, допустим 10 мс в LAN]
   
4. libspice на хосте получает сообщение
   ↓ [обработка, передача в QEMU: 1-2 мс]
   
5. Гостевая ОС получает событие клавиатуры
   ↓ [обработка в госте: 1-5 мс, зависит от загрузки]
   
6. Приложение обрабатывает нажатие, рисует букву
   ↓ [рендеринг: 1-16 мс, зависит от vsync]
   
7. QXL фиксирует изменение, отправляет
   ↓ [сеть обратно: RTT/2, ещё 10 мс]
   
8. Клиент декодирует, отображает
   ↓ [декодирование + отрисовка: 1-5 мс]
   
9. Пользователь видит букву

В идеальном LAN это 30-50 мс. В реальном LAN с загруженной сетью — 50-80 мс. Через WAN с RTT 50 мс — уже 100-130 мс. Через океан с RTT 150 мс — 200+ мс.

И это без учёта потерь пакетов. TCP при потере начинает ретрансмиты — и отдельные события могут задерживаться на сотни миллисекунд.

Где теряется больше всего

По моему опыту диагностики проблем с SPICE, основные источники задержки:

Сеть — очевидно, но часто недооценивают. Корпоративные сети бывают перегружены, особенно в часы пик. WiFi добавляет джиттер. VPN добавляет overhead.

Кстати, раньше я думал, что программисты — ночные люди, потому что никто не отвлекает. Но последние годы начинаю понимать другое: остаюсь в офисе до поздней ночи, потому что сеть не лагает. Днём — 50 человек тянут трафик, VDI подтупливает. После десяти вечера — летает. Чем-то напоминает эпоху первых мейнфреймов IBM, когда операторы работали ночами, пока машинное время дешевле.

Гостевая ОС — если VM перегружена или swapит, обработка ввода замедляется. Антивирус, индексация, обновления в фоне — всё это влияет.

Композитор в госте — Mutter, KWin, DWM добавляют кадр-два задержки. Это 16-32 мс при 60 fps. Вроде немного, но складывается.

Vsync — если включён, добавляет до 16 мс (ожидание следующего кадра). Если выключён — возможны разрывы изображения.

Клиент — медленный декодинг, композитинг на стороне клиента, особенно если клиент — слабый тонкий клиент или Raspberry Pi.

Input Channel: клавиатура и мышь

Input Channel — это канал, через который идут события ввода от клиента к серверу. Клавиатура, мышь, иногда тачпад.

Структура сообщений

Протокол здесь простой. Типичные сообщения:

SPICE_MSGC_INPUTS_KEY_DOWN      — клавиша нажата
SPICE_MSGC_INPUTS_KEY_UP        — клавиша отпущена
SPICE_MSGC_INPUTS_MOUSE_MOTION  — мышь сдвинулась
SPICE_MSGC_INPUTS_MOUSE_PRESS   — кнопка мыши нажата
SPICE_MSGC_INPUTS_MOUSE_RELEASE — кнопка мыши отпущена

Колесо мыши передаётся как MOUSE_PRESS/RELEASE с кодами кнопок 4 и 5 (вверх/вниз). Это дискретные события, не плавный скролл. При высокой latency или потерях пакетов «тики» колеса могут теряться — крутишь колесо, а страница прокручивается рывками или отстаёт.

Каждое сообщение — несколько байт. Координаты, код клавиши, состояние модификаторов (Shift, Ctrl). Ничего тяжёлого.

Важный момент: SPICE устанавливает TCP_NODELAY на сокет Input Channel. Это отключает алгоритм Nagle — тот самый, который накапливает мелкие пакеты перед отправкой, чтобы снизить overhead. Для bulk transfer это хорошо, для интерактивного ввода — катастрофа. Без TCP_NODELAY каждое нажатие клавиши могло бы ждать 40-200 мс в буфере, пока TCP решит, что пора отправлять. Попробуйте печатать с такой задержкой.

Казалось бы, что тут ещё может пойти не так?

Проблема с мышью: абсолютные vs относительные координаты

И тут начинается интересное.

Мышь может работать в двух режимах:

Относительный (relative) — мышь сообщает «сдвинулась на dx, dy пикселей». Так работает обычная мышь на обычном десктопе.

Абсолютный (absolute) — устройство сообщает «курсор должен быть в точке x, y». Так работает тачпад, графический планшет, тачскрин.

Для VDI это критически важно. Потому что клиент не знает, где находится курсор в госте. А гость не знает, где находится курсор на экране клиента.

Server Mouse Mode

По умолчанию SPICE работает в режиме, который называется server mouse mode.

Клиент отправляет относительные перемещения мыши. Гостевая ОС двигает свой курсор. Изменение позиции курсора возвращается клиенту через Cursor Channel.

Проблема: пока сообщение дойдёт до гостя и обратно — проходит RTT. Курсор на экране клиента «догоняет» реальные движения мыши.

Эффект особенно заметен при резких движениях. Вы резко двигаете мышь вправо, курсор на экране начинает двигаться с задержкой, потом «догоняет». Ощущение — будто курсор на резинке.

При RTT 20 мс это терпимо. При RTT 100 мс — уже неприятно. При RTT 200 мс — почти невозможно точно попасть по мелким элементам интерфейса.

И ещё одна радость server mode — захват мыши (mouse grab). Чтобы относительные перемещения работали корректно, клиент должен «захватить» курсор. Мышь как бы заперта внутри окна VDI. Чтобы выйти и кликнуть что-то на локальном десктопе — нужно нажать Ctrl+Alt (или другую комбинацию, зависит от клиента). Новички об этом не знают и паникуют: «Мышь сломалась!» Опытные — раздражаются каждый раз, когда забывают нажать release.

Client Mouse Mode

Альтернатива — client mouse mode. Здесь клиент сам рисует курсор поверх изображения, без ожидания ответа от сервера.

Движение мыши → клиент сразу двигает курсор → параллельно отправляет событие в гостя.

Курсор реагирует мгновенно. Красота?

Не совсем.

Во-первых, клиент должен получить изображение курсора от гостя. Курсор — это не просто стрелочка. Это может быть:

  • стрелка

  • текстовый курсор (I-beam)

  • рука (для ссылок)

  • крестик

  • песочные часы

  • кастомный курсор приложения

  • анимированный курсор

Все эти картинки должны прийти с сервера. И должны вовремя переключаться.

Во-вторых, возникает рассинхрон. Клиент показывает курсор в одной позиции, а гость думает, что курсор в другой. Особенно заметно на границах окон, при ресайзе, при drag-and-drop.

Видел случай: пользователь пытается схватить границу окна для ресайза, а она «убегает». Потому что клиент показывает курсор в одном месте, а событие мыши гость получает с задержкой и думает, что курсор уже в другом месте.

usb-tablet: компромиссное решение

Есть третий путь — эмуляция USB-планшета.

QEMU умеет эмулировать USB tablet device — устройство, которое отправляет абсолютные координаты. Клиент отправляет не «сдвинь на 10 пикселей», а «курсор в точке 500, 300».

<input type='tablet' bus='usb'/>

Плюсы:

  • Нет рассинхрона позиций

  • Позиция курсора в госте всегда соответствует позиции на клиенте

  • Не нужен grab мыши (клиент не захватывает указатель)

Минусы:

  • Относительные перемещения теряются. Если приложение ожидает дельты (некоторые игры, CAD-системы в определённых режимах) — будут проблемы

  • Дополнительный виртуальный USB-устройство в госте

  • На старых гостевых ОС может потребоваться установка драйверов

В большинстве офисных сценариев usb-tablet — лучший выбор. Проблемы начинаются со специфичными приложениями.

И ещё момент: если у вас четыре монитора — это что, четыре планшета? Или один большой виртуальный? Тут есть где словить неочевидные проблемы с координатами. А ещё смешанные режимы: при установке ОС, когда в инсталляторе нет нужных драйверов или virtio-каналов, администраторы страдают. Мышь работает в server mode, курсор лагает, попасть по кнопкам — квест. Каждый, кто ставил гостевую ОС через SPICE, знает это чувство.

Cursor Channel: почему курсор отдельно

В первой статье я упоминал, что SPICE выделяет курсор в отдельный канал. Это не академическое решение — это ответ на конкретную проблему.

Проблема

Display Channel может быть загружен. Тяжёлое изображение, сложная область, видео — всё это требует времени на сжатие и передачу. Если курсор идёт в общем потоке с картинкой, он будет «залипать» каждый раз, когда на экране что-то сложное.

Пользователь двигает мышь, а курсор замер на полсекунды, пока прокачивается очередной кадр. Это неприемлемо.

Решение

Cursor Channel — отдельное TCP-соединение с приоритетом над Display Channel (на уровне приложения, не протокола). Данные курсора маленькие и проходят быстро, даже если Display Channel загружен.

Через Cursor Channel передаётся:

  • Позиция курсора (в server mouse mode)

  • Изображение курсора

  • Команды show/hide

Передача изображений курсора

Вот на этом месте начинаются нюансы, которые редко упоминают.

Курсор — это картинка. Причём не одна картинка, а много разных. И они все должны прийти с гостя на клиент.

Когда гостевая ОС меняет курсор (навели на ссылку — стрелка стала рукой), SPICE отправляет новое изображение курсора через Cursor Channel:

SPICE_MSG_CURSOR_SET
├── position (x, y)
├── visible
├── cursor_header
│   ├── type (ALPHA, MONO, COLOR)
│   ├── width, height
│   └── hot_spot (x, y)  — точка «острия»
└── data[] — пиксели курсора

Типичный курсор — 32×32 пикселя, RGBA. Это 4 КБ. Немного, но если курсоры меняются часто (анимированный курсор, например «загрузка»), трафик накапливается.

Кэширование

SPICE кэширует курсоры. Если курсор уже был отправлен, сервер передаёт только ID:

SPICE_MSG_CURSOR_SET
└── cursor_header.unique = 12345  — «покажи курсор #12345»

Экономия трафика и latency. Но кэш ограничен, и при переполнении курсоры передаются заново.

Где бывают проблемы

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

Анимированные курсоры. Windows «песочные часы» — это анимация. Каждый кадр анимации — новое изображение. SPICE передаёт их как отдельные курсоры. При плохой связи анимация становится рваной или замирает.

High DPI курсоры. На 4K мониторах курсоры 64×64 или даже 128×128. Это уже 16-64 КБ на курсор. Умножаем на количество типов курсоров — заметный объём при первом подключении.

Курсор в client mouse mode. Клиент должен отрисовать курсор поверх изображения. Если изображение курсора не успело прийти (ещё в пути или выпало из кэша), клиент показывает устаревший курсор. Пользователь видит стрелку, когда должна быть рука. Мелочь, но раздражает.

Cursor lag при переключении. Вы переводите курсор на ссылку — гость меняет курсор на «руку» — изменение идёт через Cursor Channel — клиент получает и отрисовывает. При высокой latency переключение заметно отстаёт.

vdagent: невоспетый герой

Про vdagent обычно говорят в контексте copy-paste и динамического разрешения. Но он важен и для ввода.

Что делает vdagent

spice-vdagent — демон внутри гостя, который общается с хостом через virtio-serial. Он обеспечивает:

  • Copy-paste между клиентом и гостем

  • Drag-and-drop файлов

  • Динамическое изменение разрешения

  • Синхронизацию позиции мыши

Последний пункт критичен для client mouse mode.

Синхронизация мыши через vdagent

В client mouse mode клиент рисует курсор сам, но гость должен знать, где курсор на самом деле. Иначе клики будут попадать не туда.

vdagent решает это: получает абсолютные координаты от клиента и транслирует их в гостевую ОС. Фактически эмулирует «кликни вот здесь».

Без vdagent client mouse mode работает... странно. Клиент показывает курсор в одном месте, гость думает, что он в другом. Клики не попадают.

Когда vdagent не работает

  • Не установлен (забыли поставить пакет, нет в образе)

  • Не запущен (не стартовал демон, crashнулся)

  • Нет канала связи (не настроен virtio-serial в libvirt)

  • Старая версия (несовместимость протокола)

Симптомы: мышь ведёт себя странно, курсор прыгает, клики не попадают. Или copy-paste не работает, и тогда идут жалобы «не могу скопировать текст».

Первое, что проверяю при проблемах с вводом: ps aux | grep vdagent. Если не запущен — запускаем. Если падает — смотрим логи.

Клавиатура: проще, но не без нюансов

С клавиатурой проще, чем с мышью. Нет проблемы рассинхрона позиций — клавиша либо нажата, либо нет.

Но свои нюансы есть.

Раскладки и модификаторы

Клавиатурные раскладки — вечный источник проблем в VDI. SPICE передаёт скан-коды клавиш, а не символы. Интерпретация происходит в госте.

Если раскладка на клиенте и в госте не совпадает — получаете не те символы. Или модификаторы залипают. Или Caps Lock работает инверсно.

Особенно весело с:

  • Не-US раскладками

  • Переключением раскладок хоткеями

  • AltGr на европейских клавиатурах

  • Mac-клавиатурами (Cmd vs Ctrl)

Key repeat

Зажатая клавиша должна повторяться. Где происходит repeat — на клиенте или в госте?

В SPICE — в госте. Клиент отправляет KEY_DOWN, гость сам генерирует повторы, потом клиент отправляет KEY_UP.

Проблема: если KEY_UP потерялся или задержался (привет, TCP retransmit), клавиша «залипает». Гость думает, что клавиша всё ещё нажата.

Я видел такое на нестабильных WAN-соединениях. Пользователь нажал стрелку вниз, отпустил — а курсор продолжает ехать вниз. Потому что KEY_UP застрял в ретрансмитах.

Народное средство — быстро много раз нажать на залипшую клавишу. Иногда помогает протолкнуть KEY_UP. Чем-то напоминает работу на первых персоналках с их капризными клавиатурами. Прогресс, говорили они.

Хоткеи

Некоторые комбинации клавиш перехватываются клиентом:

  • Shift+F12 — toggle fullscreen (по умолчанию в remote-viewer)

  • Ctrl+Alt — release grab

Если пользователь ожидает, что Shift+F12 сделает что-то в приложении внутри VM — сюрприз.

Конфигурируется, но надо знать.

Практические ориентиры по latency

После всей этой теории — что делать на практике?

Измерение latency

Первый шаг — понять, какая latency у вас есть.

Сетевая latency: простой ping между клиентом и хостом. Умножаем на 2 — это baseline RTT без учёта обработки.

End-to-end latency: сложн��е измерить. Один способ — использовать внешнюю камеру:

  1. Показать таймер на клиенте (локальное приложение)

  2. Показать таймер в VDI-сессии

  3. Снять оба на камеру

  4. Измерить разницу покадрово

Звучит по-колхозному, но работает. Есть и специализированные инструменты (Ldat от NVIDIA, например), но камера доступнее.

Input latency отдельно: некоторые запускают в госте приложение, которое рисует круг под курсором с минимальной задержкой. Разница между позицией реального курсора и круга — input latency.

Приемлемые значения

Субъективно, из опыта:

RTT сети

End-to-end

Ощущение

<10 мс

<50 мс

Как локально

10-30 мс

50-80 мс

Хорошо

30-50 мс

80-120 мс

Терпимо для офиса

50-100 мс

120-180 мс

Заметно, но работать можно

100 мс

200 мс

Проблемы

Это для обычных пользователей. Дизайнеры, CAD-операторы, геймеры чувствительнее — для них границы сдвигаются вниз.

Что можно оптимизировать

Сеть — главный рычаг. Уменьшить RTT между клиентом и хостом. Прямой маршрут, минимум хопов, QoS для SPICE-трафика. Если пользователи удалённые — размещать VDI ближе к ним.

Гостевая ОС. Отключить визуальные эффекты и композитор, если возможно. Меньше анимаций — меньше задержек. Не перегружать VM.

Client mouse mode. Если RTT высокий, client mouse mode даёт субъективно лучший отклик. Но нужен работающий vdagent.

usb-tablet. Практически всегда стоит включить. Устраняет проблемы с захватом мыши и синхронизацией.

Проверить vdagent. Удивительно часто проблемы с вводом — это просто неработающий vdagent.

Чего SPICE не умеет (и наверное не будет)

Честно про ограничения.

Предиктивный ввод

Некоторые коммерческие решения используют prediction — клиент пытается предсказать, как отреагирует сервер, и показывает результат до получения реального ответа. Потом корректирует, если ошибся.

Citrix и VMware это умеют для определённых сценариев (скроллинг, печать). SPICE — нет. Каждый отклик ждёт реального ответа от сервера.

UDP transport

TCP гарантирует доставку, но при потерях это означает ретрансмиты и задержки. Для real-time ввода иногда лучше потерять событие, чем задержать всё остальное.

SPICE — TCP only. Обсуждалось много лет, не реализовано.

Локальный эхо для печати

Когда вы печатаете текст, клиент мог бы сразу показывать вводимые символы локально, не дожидаясь ответа от сервера. При несовпадении — корректировать.

Технически сложно (нужно понимать контекст — где курсор, какой шрифт, какое приложение), в SPICE не реализовано.

Бизнес-последствия

Вернёмся к тому, с чего начали.

Скрытая стоимость плохого отклика

Плохой отклик не виден в метриках, но имеет реальную цену:

Снижение продуктивности. Исследования (да, реальные исследования, не маркетинговые) показывают падение продуктивности на 1-2% на каждые 50 мс дополнительной latency для задач, требующих точного ввода. Мелочь? На 1000 сотрудников это 10-20 FTE.

Усталость. Люди устают быстрее. Больше ошибок к концу дня. Больше больничных (это уже спекуляция, но логика понятна).

Сопротивление системе. Пользователи ищут способы обойти VDI. Работают с телефона. Просят исключения. Саботируют внедрение.

Репутация IT. «Они нам поставили тормозящую систему.» Восстанавливать доверие потом — долго и дорого.

Когда SPICE достаточно хорош

При всём сказанном, SPICE в LAN с RTT <20 мс даёт отклик, который большинство пользователей не отличит от локального. Для офисной работы — текст, таблицы, почта, браузер — этого достаточно.

Проблемы начинаются:

  • На WAN с высоким RTT

  • Для чувствительных к отклику задач (дизайн, CAD)

  • При нестабильной сети с потерями

Знать эти границы — значит правильно позиционировать решение. Не обещать того, чего SPICE не даст. И не отказываться от него там, где он работает отлично.

Итог

Отклик на ввод — это то, что определяет субъективное качество VDI больше, чем битрейт и разрешение. Человек адаптируется к мыльной картинке, но не адаптируется к задержке между движением руки и реакцией на экране.

SPICE разделяет ввод и курсор на отдельные каналы, что архитектурно правильно. Cursor Channel позволяет курсору двигаться плавно, даже когда Display Channel загружен. Client mouse mode снижает воспринимаемую задержку за счёт локальной отрисовки курсора.

При этом usb-tablet — практически обязательная опция для нормальной работы. Без него начинаются проблемы с синхронизацией позиции мыши. vdagent — тоже must have, особенно для client mouse mode и copy-paste.

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

В хорошей LAN-сети SPICE даёт отклик, сравнимый с локальным. В WAN с высоким RTT начинаются компромиссы, которые не всегда можно решить на стороне протокола. Это фундаментальное ограничение, связанное с физикой и TCP-архитектурой.

Понимание того, как устроен ввод в SPICE, помогает диагностировать реальные проблемы (часто это просто неработающий vdagent) и правильно устанавливать ожидания — свои и пользовательские.

В следующей статье: Звук в SPICE — аудио, микрофон и real-time ограничения. Почему playback проще, чем capture. Почему голосовые звонки через VDI — отдельный класс проблем. И что делать, когда «меня не слышно».