On 05/26/2012 01:07 PM, David G. Miller wrote: > Arun Khan <knura9 at ...> writes: > >> On Sat, May 26, 2012 at 4:59 PM, Jerry Geis <geisj at ...> wrote: >>> I have my machine CentOS 6.2 running KVM guest of Windows 7. > <SNIP> >>> Then when I remote in using VNC to my machine - the VNC always >>> works fine. However, when I try to access the KVM session its like >>> the mouse has lost its brain. >>> >>> Anyone ran into this? > <SNIP> >>> Each guest VM can have it's own vnc console (look at the kvm man >> page). With VNC enabled for your Win7 VM, you can access the Win7 >> console directly w/o having to go through your CentOS desktop. >> >> HTH, > I've seen this behaviior with VMware and Xen also as well as KVM. One level of > virtualization works fine but two levels of virtualizing the display and the > mouse appears to be a bit much for the current level of the technology and it > doesn't seem to matter which virtualization platform you use. > > The Arun's response is probably your best bet for acceptable behavior. You just > need to make the network interface for the VM as visible as your desktop's. What David said ... think about what you are trying to do ... You are trying to virtualize an already virtualized display. That doesn't usually work, no matter what you are using to do it. (VMware, Xen, even 2 layers deep of VNC) BUT, spice is made for just this scenario. With SPICE, if you turn it on on the VM host, you would just connect to port 5900 (for the first VM, 5901 for the 2nd, etc) with the spicy client from your remote machine. This way, you are not trying to connect directly to the VM's network card. You need to control where you can connect from (just like you would for VNC) ... but it should solve your issue. http://wiki.centos.org/HowTos/Spice-libvirt You would need to -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 262 bytes Desc: OpenPGP digital signature URL: <http://lists.centos.org/pipermail/centos/attachments/20120529/964d0436/attachment-0005.sig>