LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Virtualization and Cloud (http://www.linuxquestions.org/questions/linux-virtualization-and-cloud-90/)
-   -   multiple full screen VMs (http://www.linuxquestions.org/questions/linux-virtualization-and-cloud-90/multiple-full-screen-vms-4175426184/)

Skaperen 09-07-2012 08:16 PM

multiple full screen VMs
 
I'm thinking maybe Xen can do this. But any VM engine that can would be of interest. QEMU apparently cannot.

I want to have two or more guest VMs (not counting dom0 in Xen) operating in full screen mode, with their respective X server having access to all keyboard keystrokes and chords EXCEPT the key chord used to switch the display between VMs (or the kernel SysRQ chords). Then within each VM, I might run an X server and desktop environment with compositors like Compiz. And I'd like for any guest to be able to do HVM (e.g. guest not modified for the VM) or PV-on-HVM.

So I could use some keychord like Shift+Ctrl+Alt+F1 to switch between VMs, with all other keychords not defined to switch VMs be sent to the VM (like any/every Ctrl+Alt+SomeKey)?

And what about a frame buffer text console? And switching that to X with Ctrl+Alt+F7? And to the 2nd instance of X at Ctrl+Alt+F8? And back to text console at Ctrl+Alt+F2? ... all inside whatever VM is currently selected ... and then selecting another VM and do it all again there?

If it can't do this, I don't want to waste time on such a big TIAS. The idea is to be "on" only ONE VM at a time (as opposed to 2 or move visible at the same time in windows as I see in so many examples) so that it makes sense for EVERY keystroke to go to that virtual machine (no need to focus, no risk of the host X instance doing the keystrokes like shutting down from Ctrl+Alt+BackSpace).

Ygrex 09-09-2012 04:02 PM

Xorg is network transparent by design, so you can run X-instances on the host machine and make guests' composite WMs to connect to these displays

Skaperen 09-09-2012 09:51 PM

Quote:

Originally Posted by Ygrex (Post 4776329)
Xorg is network transparent by design, so you can run X-instances on the host machine and make guests' composite WMs to connect to these displays

My question is not about connecting window managers. It's about how to switch between different virtual machines so that the Xorg running within each can be in control of the console.

I want the virtual machine to be in full control of the console, and Xorg running in that virtual machine to be the software with access. But I want each virtual machine to operate that way. Then something needs to be able to switch which virtual machine will be the one that is active on the console. And whatever that is best to not be something that X expects to get for some purpose.

Other virtual machine engines just open up windows to a host X server. Xen's design is different, and it MAY allow this kind of thing, where each VM's X server can take control of the real console.

gezley 09-10-2012 12:06 AM

Quote:

Originally Posted by Skaperen (Post 4775356)
I'm thinking maybe Xen can do this. But any VM engine that can would be of interest. QEMU apparently cannot.

I want to have two or more guest VMs (not counting dom0 in Xen) operating in full screen mode, with their respective X server having access to all keyboard keystrokes and chords EXCEPT the key chord used to switch the display between VMs (or the kernel SysRQ chords). Then within each VM, I might run an X server and desktop environment with compositors like Compiz. And I'd like for any guest to be able to do HVM (e.g. guest not modified for the VM) or PV-on-HVM.

So I could use some keychord like Shift+Ctrl+Alt+F1 to switch between VMs, with all other keychords not defined to switch VMs be sent to the VM (like any/every Ctrl+Alt+SomeKey)?

And what about a frame buffer text console? And switching that to X with Ctrl+Alt+F7? And to the 2nd instance of X at Ctrl+Alt+F8? And back to text console at Ctrl+Alt+F2? ... all inside whatever VM is currently selected ... and then selecting another VM and do it all again there?

If it can't do this, I don't want to waste time on such a big TIAS. The idea is to be "on" only ONE VM at a time (as opposed to 2 or move visible at the same time in windows as I see in so many examples) so that it makes sense for EVERY keystroke to go to that virtual machine (no need to focus, no risk of the host X instance doing the keystrokes like shutting down from Ctrl+Alt+BackSpace).

Not sure I understand you fully. In Xen you would need X running on the dom0, regardless, because dom0 controls the physical display. You can then use XDMCP to connect to X on your domUs. So let's say you have X running on dom0 at display :0 (not a good idea having X on dom0 but leave that aside for the time being). Now go to your first virtual terminal with Ctrl+Alt+F2 and then use something like the following to get X on your first domU at display :1

Code:

X -query 10.40.0.2 :1
Something like Ctrl+Alt+F8 should then take you to a login screen on display :1 for your first domU. Log in and you will then be using the X server of the domU.

Now go to your second virtual terminal with Ctrl+Alt+F3 and then connect to X on your second domU:

Code:

X -query 10.50.0.2 :2
Something like Ctrl+Alt+F9 will take you to a login screen on display :2 for your second domU.

And so on.

Needless to say you need XDMCP and networking set up on your domUs. Just use VNC for initial setup.

I don't think you will be able to open virtual terminals within each domU. As I say, in Xen dom0 controls the physical console together with the virtual terminals. In NetBSD I get 4 VTs; in Slackware 6.

I have done the same in KVM-Qemu by the way. XDMCP speed is near-native, if you use high-speed virtual network interfaces.

Skaperen 09-11-2012 11:35 PM

Quote:

Originally Posted by gezley (Post 4776536)
Not sure I understand you fully. In Xen you would need X running on the dom0, regardless, because dom0 controls the physical display. You can then use XDMCP to connect to X on your domUs. So let's say you have X running on dom0 at display :0 (not a good idea having X on dom0 but leave that aside for the time being). Now go to your first virtual terminal with Ctrl+Alt+F2 and then use something like the following to get X on your first domU at display :1

You say it is needed to run X on dom0 ... and it is not a good idea? Seems like a conflict.
Quote:

Originally Posted by gezley (Post 4776536)
Code:

X -query 10.40.0.2 :1
Something like Ctrl+Alt+F8 should then take you to a login screen on display :1 for your first domU. Log in and you will then be using the X server of the domU.

Now go to your second virtual terminal with Ctrl+Alt+F3 and then connect to X on your second domU:

Code:

X -query 10.50.0.2 :2
Something like Ctrl+Alt+F9 will take you to a login screen on display :2 for your second domU.

And so on.

OK, so basically I'd have multiple instances of X on dom0, and switch between X instance just like if I did not run Xen, except the extra instances would be connected to from the various domUs.

Quote:

Originally Posted by gezley (Post 4776536)
Needless to say you need XDMCP and networking set up on your domUs. Just use VNC for initial setup.

So what is VNC connecting to? A separate Xvnc instance inside each domU?

Quote:

Originally Posted by gezley (Post 4776536)
I don't think you will be able to open virtual terminals within each domU. As I say, in Xen dom0 controls the physical console together with the virtual terminals. In NetBSD I get 4 VTs; in Slackware 6.

My Slackware is modified to have 60 VTs and 3 Xs (moved to be at Ctrl+Alt+F10, Ctrl+Alt+F11, and Ctrl+Alt+F12). My Ubuntu has the first X at Ctrl+Alt+F7 as per default. If I do a user switch, another X gets started at Ctrl+Alt+F8. Then I can do the Ctrl+Alt+F(7 or 8) switching.

Quote:

Originally Posted by gezley (Post 4776536)
I have done the same in KVM-Qemu by the way. XDMCP speed is near-native, if you use high-speed virtual network interfaces.

One of my goals is to expand on the number of console/desktops I can switch to directly (without it going through X ... just by being on X). Basically the problem will be that keystrokes like Ctrl+Alt will apply to the "front facing" X and not to the X in the virtual machine. So Xen won't accomplish what I wanted. I guess I have to go back to a single non-virtual system with multiple instances of X switching the console.

gezley 09-12-2012 08:44 AM

Quote:

Originally Posted by Skaperen (Post 4778147)
You say it is needed to run X on dom0 ... and it is not a good idea? Seems like a conflict.

From a security (and performance) point of view it's not a good idea to run more than necessary on dom0, but if you do want a GUI while you're sitting at the physical console, then you have to run X. You don't need X running or indeed installed on dom0 if your server is headless and you access the domUs from another machine, using XDMCP, RDP, VNC, or whatever.

Quote:

OK, so basically I'd have multiple instances of X on dom0, and switch between X instance just like if I did not run Xen, except the extra instances would be connected to from the various domUs.

So what is VNC connecting to? A separate Xvnc instance inside each domU?
You could use VNC or SDL just for initial setup of the domU. Xen looks after the VNC server for you. It's just a temporary measure so that you can set up networking inside the domU, and once that's done you can use XDMCP, RDP or indeed a full VNC server inside the domU instead.

Quote:

One of my goals is to expand on the number of console/desktops I can switch to directly (without it going through X ... just by being on X). Basically the problem will be that keystrokes like Ctrl+Alt will apply to the "front facing" X and not to the X in the virtual machine. So Xen won't accomplish what I wanted. I guess I have to go back to a single non-virtual system with multiple instances of X switching the console.
I don't think Xen can handle this, since dom0 always has control of the physical console and virtual terminals. Even if you go with XDMCP, where X runs on the domU, you still need a local X server (in this case, on the dom0). When you're trying to do all of this in a virtual setup X becomes a circular dependency really. The bottom line with Xen is that dom0 always retains control of the physical console and input.

Skaperen 09-18-2012 04:38 PM

Quote:

Originally Posted by gezley (Post 4778489)
From a security (and performance) point of view it's not a good idea to run more than necessary on dom0, but if you do want a GUI while you're sitting at the physical console, then you have to run X. You don't need X running or indeed installed on dom0 if your server is headless and you access the domUs from another machine, using XDMCP, RDP, VNC, or whatever.

There are ways to do graphics on the console w/o X.

Quote:

Originally Posted by gezley (Post 4778489)
You could use VNC or SDL just for initial setup of the domU. Xen looks after the VNC server for you. It's just a temporary measure so that you can set up networking inside the domU, and once that's done you can use XDMCP, RDP or indeed a full VNC server inside the domU instead.

Quote:

Originally Posted by gezley (Post 4778489)
I don't think Xen can handle this, since dom0 always has control of the physical console and virtual terminals. Even if you go with XDMCP, where X runs on the domU, you still need a local X server (in this case, on the dom0). When you're trying to do all of this in a virtual setup X becomes a circular dependency really. The bottom line with Xen is that dom0 always retains control of the physical console and input.

What I though Xen might have been doing was managing the real physical console and allowing the user selected domX to use it, where the video, keyboard, and mouse would all be switched as in a virtual KVM. Since Xen can't do this, I would be interested in finding something that can, if anything like this has been made. But given the way Xen is really the first layer above metal, this is where such a feature could be placed.

My objective is RAPID ... as in just ONE keychord action ... or maybe TWO such actions (one for a VM layer and one for a VC/VD layer) ... switching of a very large number of desktops (over 100 ... goal 240). Had Xen been able to do this, I would have set up a few domUs and run X+Compiz in each, and configure Compiz for direct keychord switching (which it is currently limited to 12 desktops by this means). I am doing 36 desktops in one instance of Compiz, now, but with desktop sliding. I want something better, such as direct switching.


All times are GMT -5. The time now is 12:36 PM.