Those patches are supposed to be added to mainline at some point. They are stable and work great! On 29 Feb 2016 20:33, "Will Marler" <[email protected]> wrote:
> Oh, good point, that is an option too (although I personally I stay away > from patching) > > On Mon, Feb 29, 2016 at 1:29 PM, Jonathan Scruggs <[email protected]> > wrote: > >> For keyboard and mouse, grab the patches in this mailing list that pass >> through your host keyboard and mouse as a standard PS/2 device. You press >> both CTRL keys to switch between host and guest. Works very well. You also >> have full BIOS control of the guest and Windows UAC pop-ups can be clicked >> on where as synergy gets blocked by those prompts. >> On 29 Feb 2016 17:44, "Will Marler" <[email protected]> wrote: >> >>> a) I've never had Host or Guest crash problems. I have had problems with >>> programs crashing in the guest with nebulous errors (or no errors) that >>> seem related to graphics. They are reproducible, but not reliably so, and I >>> have never tried to verify if those crashes exist on baremetal. >>> >>> d) Synergy works great for simple functions (when you need keyboard & >>> 2-button mouse). In my experience it is not a good solution for games, as >>> some games will interpret the mouse inputs weirldy (small physical mouse >>> movements resulting in HUGE cursor movements), and the full spectrum of >>> buttons doesn't get translated through. >>> >>> On Sat, Feb 27, 2016 at 1:02 AM, Rokas Kupstys <[email protected]> wrote: >>> >>>> b) VM even if qemu runs as root is still more secure than running >>>> software in your own session. More things need to be broken to get to the >>>> host with virtualisation in place. >>>> >>>> c) virt-manager can do almost all whats needed. Might need to edit xmls >>>> by hand to switch it to uefi though. Or to add few flags not supported by >>>> virt-manager, but as far as device assignment goes virt-manager does handle >>>> it. >>>> >>>> >>>> On 2016.02.26 23:09, Muted Bytes wrote: >>>> >>>> From my experience: >>>> >>>> I would consider usage stable for an average user, but I'm not sure >>>> about set-up for a non-technical user. >>>> >>>> a) In my specific case, I am forced to use Windows because a lot of >>>> simulation and computational tools are only available on that platform, but >>>> I chose to operate in a VM rather than baremetal. As a result, I have both >>>> memory and cpu intensive simulations running in the guest for days at a >>>> time, and idle for weeks/months (shutdown only for host maintenance etc). >>>> Have never had guest or host crash or freeze (even through guest restarts). >>>> >>>> b) I cannot provide comment, I am also running qemu as root. I intend >>>> to look at how to move away from root execution of qemu but haven't yet >>>> (virtsh makes this easier/possible from what I've read but haven't looked >>>> in detail). >>>> >>>> c) I am also still using qemu from command-line so cannot comment, but >>>> I have been watching progression of virtsh and virt-manager. I think it >>>> already is at/getting to that point. >>>> >>>> d) I am using synergy to switch between screens/share kb and mouse with >>>> guest. In my case, if the mouse is left on guest side, the guest can lock >>>> but synergy prevents the host from locking. The mouse needs to be on host >>>> side for me. Also, my guest and host lock independently, so I'm not sure if >>>> there is a way to synchronize this. >>>> Copy/paste generally works well with text in both directions, however >>>> there seem to be some issues with more recent versions of synergy upstream >>>> that makes the server portion to hang/crash that seems to be related to the >>>> copy buffer (though I'm not 100% sure this is the cause). I haven't >>>> encountered this in a while, so it has been intermittent in my case. One >>>> good thing about synergy is that you can set it up so that scroll lock key >>>> will lock the mouse/kb to one side (guest or host) if you plan to work or >>>> game in that environment for a long session, and don't want the mouse to >>>> accidentally switch context on the screen edge/boundary. This also makes >>>> fullscreen and FPS games playable in the guest without the mouse going nuts >>>> from losing relative position information. >>>> On Feb 25, 2016 22:59, "Daniel Pocock" <[email protected]> wrote: >>>> >>>>> >>>>> Is a passthrough VGA configuration currently considered stable and >>>>> secure for widespread use, for example, where non-technical users can >>>>> work productively with applications running this way in an office >>>>> environment? >>>>> >>>>> Some specific things come to mind: >>>>> >>>>> a) crashes: I've seen crashes mentioned in a few discussions, but are >>>>> there many people running it for days and weeks at a time without >>>>> crashes? Are such issues specific to particular hardware and can they >>>>> be avoided by using hardware that is preferred/more heavily tested by >>>>> the developers? >>>>> >>>>> b) security: in my testing so far, I just run the qemu command as root. >>>>> To what extent can the use of root privileges be avoided? I realize a >>>>> VM is never 100% secure compared to a normal user session. >>>>> >>>>> c) control: some of the blogs and wikis mention that tools like >>>>> virt-manager and virt-install don't fully cope with passthrough VGA >>>>> configuration, is that still up to date? Can the user start and manage >>>>> the VM using some GUI from their X desktop on their host display? >>>>> >>>>> d) interaction between VM and host desktop: when the user locks the >>>>> host >>>>> display (screensaver), can this also lock the VM's passthrough display, >>>>> or the user will always need to lock both? How well does something >>>>> like >>>>> Synergy work across the displays, especially for things like >>>>> cut-and-paste? >>>>> >>>>> _______________________________________________ >>>>> vfio-users mailing list >>>>> [email protected] >>>>> https://www.redhat.com/mailman/listinfo/vfio-users >>>>> >>>> >>>> >>>> _______________________________________________ >>>> vfio-users mailing >>>> [email protected]https://www.redhat.com/mailman/listinfo/vfio-users >>>> >>>> >>>> >>>> _______________________________________________ >>>> vfio-users mailing list >>>> [email protected] >>>> https://www.redhat.com/mailman/listinfo/vfio-users >>>> >>>> >>> >>> _______________________________________________ >>> vfio-users mailing list >>> [email protected] >>> https://www.redhat.com/mailman/listinfo/vfio-users >>> >>> >
_______________________________________________ vfio-users mailing list [email protected] https://www.redhat.com/mailman/listinfo/vfio-users
