remmina + qemu + linux client == горе с буфером обмена

У меня есть хост kubuntu, работающий 19.04, и remmina установлена ​​с remmina-next. Гость - это обычная Ubuntu 19.04, доступ к которой осуществляется по протоколу Spice.

Более половины копий буфера обмена «съедаются» хостом: при копировании в буфер обмена гость не скопировал элемент. Вместо этого я найду его в буфере обмена хоста - конечно, его нельзя будет вставить в клиент.

Подробнее:

  • копирование / вырезание в буфер обмена обычно не работает с первой попытки
  • Буфер обмена клиента «узнает», что что-то не так, когда вырезка / копирование не выполняется. t работа: он не вставит ранее успешный элемент. Ниже приведен пример сверхъестественного поведения
  • . Вторая попытка почти всегда работает
  • , поскольку я не знаю, сработало ли копирование, я замечу это, когда не удастся вставить
  • затем я снова копирую / вставляю - с> 80% -ной вероятностью успеха
  • Иногда на второй копии, теперь окончательно скопированный элемент будет немедленно вставлен туда, где я ранее безуспешно пытался вставить его. Это особенно странно - точно так же, как в редакторе был заполнитель, ожидающий, что что-то попадет в буфер обмена. В зависимости от редактора, он может просто вставить сразу после копирования элемента (поэтому я получаю дубликат в редакторе)
  • Я использую CopyQ для менеджера буфера обмена в гостевой системе, но ничего не меняется, если я удалите его и используйте встроенный буфер обмена

Я заметил это только для гостей Linux, но не для гостей Windows. Я также попробовал virt-viewer, но он страдает от той же проблемы. То же самое при доступе к гостю через RDP.

Я нашел несколько старых тем об ошибке в буфере обмена Remmina, но ничего недавнего.

Как я могу диагностировать и устранить эту проблему?

Редактировать: Я изменил настройку Video QXL с VirtIO на QXL, и проблема значительно уменьшилась. Это не ушло, но проблема сейчас возникает примерно в одной из десяти копий в буфер обмена.

2
задан 26 June 2019 в 09:52

1 ответ

Отказ от ответственности: это - обходное решение, не решение.

Вчера проблема была так безумно серьезна, что я решил наконец сдаться и пойти, выбирают нулевой клиент, который я спрятал в шкафу. Это - NUC начального уровня с i3/4GB/128GB внутри.

Проблемы не стало!!!

Кажется, что проблема только испытана, если хост является одновременно также средством просмотра!

Edit2: HA!!!! Я нашел его: проблема только происходит на хостах kubuntu! Вчера я получил доступ к компьютеру от своего домашнего ПК, рабочий kubuntu 18.04 и проблема были сразу очевидны.

Наблюдения для людей, сталкивающихся с этим:

  • Набор видеодрайвера к QXL привел к КРУПНОМУ использованию пропускной способности - 1Gbit/s, и это было все еще несколько вяло. Мое разрешение 3440x1440. Использование пропускной способности было постоянным независимо от случая на экране VM. Бесполезный на WiFi (433Mbit/s), хорошо на Гбите LAN.
  • Измененный gfx драйвер к VirtIO и теперь я наслаждаюсь гладким парусным спортом. Некоторое незначительное соединение при просмотре видео, но я не использую эти VMs для видео...
  • Дополнительное примечание: при работе по WiFi это немного более вяло, но все еще довольно применимо. При работе по Гбиту LAN это почти столь же хорошо, как RDP к хосту Windows 10. Клиент Remmina 1.3.4 в обоих случаях.
  • Еще одно примечание производительности: производительность драйвера VirtIO по WAN (20/4 Мбит / s) близко к бесполезному. Каждый видит обновления и перетаскивание окна на 2560x1440, дисплей является слайд-шоу на 1 кадр/с.

Так, я мог сказать, что я довольно счастлив теперь. Удивление, если я мог бы использовать специю для удаленного доступа к реальным машинам также ;-)

0
ответ дан 2 December 2019 в 06:10

Другие вопросы по тегам:

Похожие вопросы: