當 RStudio 執行時，複製和粘貼在 KVM 虛擬機（Ubuntu）中不可用
設置：
帶有執行 Ubuntu 18.04.1 的 KVM/qemu 虛擬機的 Fedora 30。
（這個設置是因為我想在我的 Fedora 30 上執行 RStudio，它只是在 nouveau 圖形子系統的某個地方立即停止執行——但在 Ubuntu VM 中執行良好）。
問題：
當 RStudio 執行時，在 VM 中複製和粘貼是正確的 PITA。
虛擬機啟動後，主機和虛擬機之間的複制粘貼效果很好，虛擬機內部的複制粘貼效果也很好（例如KWrite to KWrite）
在 VM 中啟動 RStudio 後，複製和粘貼最初會繼續工作（幾次），但很快就會開始“鎖定”。這適用於 RStudio 和 KWrite，並且適用於虛擬機內和主機到虛擬機的複制和粘貼。虛擬機中的接收程序凍結並且顯然在等待某些東西。但是，虛擬機繼續正常執行（例如，您可以使用 shell、執行
top等iotop）接收過程會在 10-30 秒後再次喚醒，此時粘貼的文本可能已被接收……或沒有。在第一次打嗝之後，粘貼通常會失敗，這包括從 VM 複製粘貼到主機。在 KWrite 中粘貼始終需要 10 秒，直到游標返回而沒有剪貼板內容。RStudio 的行為更具災難性，有時殺死程序是唯一的解決方案。
如果一個人離開虛擬機一段時間，另一個人有機會成功執行一些複製粘貼操作，然後再次發生鎖定。
在客戶機上重新啟動
spice-vdagent(systemctl start spice-vdagentd)（而不是在它顯然什麼都不做的主機上）會中斷鎖定，並可能有機會再次執行一些複製粘貼。但是這個動作充滿了一些風險，因為我在某個時候凍結了整個 GUI。怎麼解決？
我應該尋找什麼？
我已經
xclipboard在主機上使用過查看剪貼板中的內容。沒有什麼意外的看到。附言
VM 已獲得大量 RAM (10GiB)，這似乎是必要的，因為即使是涉及強度圖的不太大的 knit 文件也會導致
pandoc記憶體不足。當我在其中工作時，RStudio 有時會自行凍結幾秒鐘，而不會鎖定整個系統。感覺好像交換或垃圾收集開始了，但在 I/O 或 CPU 方面沒有任何進展。煩人但可以生存。
在 RStudio 社區 BB 上，提供了以下想法：
設置環境變數
RSTUDIO_NO_CLIPBOARD_MONITORING=1例如：
RSTUDIO_NO_CLIPBOARD_MONITORING=1 /usr/bin/rstudio其基礎是 GitHub 上的這個錯誤修復：
基於這個問題：
我們發現：
看起來罪魁禍首可能是 RStudio 過度積極地監聽剪貼板的變化。看：
#9 0x00000000005a2745 in rstudio::desktop::GwtCallback::onClipboardChanged(QClipboard::Mode) ()我們這樣做是為了支持全域滑鼠選擇，但也許這樣做過於激進，或者我們正在處理我們應該忽略的剪貼板通知。
執行上述操作可以改善響應時間，但不會改善可靠的複制粘貼。