Need qemu to run headless on host, but still forward graphical output via x11
I have a headless host with qemu installed. I can ssh into the host, and forward x11 so I can view graphical output.
However, when I try to run qemu, I get the following error:
Could not initialize SDL(No available video device) - exiting
The -display
none and -nographic
arguments don't help, because I do want the graphical output sent over the SSH tunnel. But I don't have a monitor on the host machine.
Any thoughts on how I can get around this? Also, unfortunately, vnc is not an option per the organization's policy.
ssh xorg qemu linux-kvm
add a comment |
I have a headless host with qemu installed. I can ssh into the host, and forward x11 so I can view graphical output.
However, when I try to run qemu, I get the following error:
Could not initialize SDL(No available video device) - exiting
The -display
none and -nographic
arguments don't help, because I do want the graphical output sent over the SSH tunnel. But I don't have a monitor on the host machine.
Any thoughts on how I can get around this? Also, unfortunately, vnc is not an option per the organization's policy.
ssh xorg qemu linux-kvm
add a comment |
I have a headless host with qemu installed. I can ssh into the host, and forward x11 so I can view graphical output.
However, when I try to run qemu, I get the following error:
Could not initialize SDL(No available video device) - exiting
The -display
none and -nographic
arguments don't help, because I do want the graphical output sent over the SSH tunnel. But I don't have a monitor on the host machine.
Any thoughts on how I can get around this? Also, unfortunately, vnc is not an option per the organization's policy.
ssh xorg qemu linux-kvm
I have a headless host with qemu installed. I can ssh into the host, and forward x11 so I can view graphical output.
However, when I try to run qemu, I get the following error:
Could not initialize SDL(No available video device) - exiting
The -display
none and -nographic
arguments don't help, because I do want the graphical output sent over the SSH tunnel. But I don't have a monitor on the host machine.
Any thoughts on how I can get around this? Also, unfortunately, vnc is not an option per the organization's policy.
ssh xorg qemu linux-kvm
ssh xorg qemu linux-kvm
edited Jan 9 '16 at 9:23
AndroidNoobie
asked Jan 8 '16 at 18:00
AndroidNoobieAndroidNoobie
11324
11324
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
As counterintuitive as it seems VNC is an option: Run the guest with a VNC console, which you completely ignore, then use X over ssh to do the normal work.
We are running this setup with literally hundreds of Linux, BSD and Windows (RDP instead of X) guests and it works fine.
You can simply lock down VNC binding to localhost, if you are concerned about the security aspects.
I apologize, I meant VNC isn't an option as a matter of organization policy. But it's starting to sound like that might be the only way.
– AndroidNoobie
Jan 9 '16 at 9:23
Just use VNC and treat it as /dev/null. This makes the guest happy and doesn't stand in the way. Besides: If you manage to make your guest's network unusable (typo in /etc/network/interfaces), you have a way out.
– Eugen Rieck
Jan 9 '16 at 13:51
add a comment |
you do not need VNC
just use -nographic and ssh tunnel (works for me, so it should work for you too)
-nographic means that qemu doesn't simulate a GPU, but if you ssh forward the screen anyway then it doesn't matter, less overhead than VNC too (not that it matters much)
you basically tell the guest programs that "hey, you need a screen? I have a screen for you" and then send all the screen data through ssh, instead of using a physical device on the guest
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "3"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1023636%2fneed-qemu-to-run-headless-on-host-but-still-forward-graphical-output-via-x11%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
As counterintuitive as it seems VNC is an option: Run the guest with a VNC console, which you completely ignore, then use X over ssh to do the normal work.
We are running this setup with literally hundreds of Linux, BSD and Windows (RDP instead of X) guests and it works fine.
You can simply lock down VNC binding to localhost, if you are concerned about the security aspects.
I apologize, I meant VNC isn't an option as a matter of organization policy. But it's starting to sound like that might be the only way.
– AndroidNoobie
Jan 9 '16 at 9:23
Just use VNC and treat it as /dev/null. This makes the guest happy and doesn't stand in the way. Besides: If you manage to make your guest's network unusable (typo in /etc/network/interfaces), you have a way out.
– Eugen Rieck
Jan 9 '16 at 13:51
add a comment |
As counterintuitive as it seems VNC is an option: Run the guest with a VNC console, which you completely ignore, then use X over ssh to do the normal work.
We are running this setup with literally hundreds of Linux, BSD and Windows (RDP instead of X) guests and it works fine.
You can simply lock down VNC binding to localhost, if you are concerned about the security aspects.
I apologize, I meant VNC isn't an option as a matter of organization policy. But it's starting to sound like that might be the only way.
– AndroidNoobie
Jan 9 '16 at 9:23
Just use VNC and treat it as /dev/null. This makes the guest happy and doesn't stand in the way. Besides: If you manage to make your guest's network unusable (typo in /etc/network/interfaces), you have a way out.
– Eugen Rieck
Jan 9 '16 at 13:51
add a comment |
As counterintuitive as it seems VNC is an option: Run the guest with a VNC console, which you completely ignore, then use X over ssh to do the normal work.
We are running this setup with literally hundreds of Linux, BSD and Windows (RDP instead of X) guests and it works fine.
You can simply lock down VNC binding to localhost, if you are concerned about the security aspects.
As counterintuitive as it seems VNC is an option: Run the guest with a VNC console, which you completely ignore, then use X over ssh to do the normal work.
We are running this setup with literally hundreds of Linux, BSD and Windows (RDP instead of X) guests and it works fine.
You can simply lock down VNC binding to localhost, if you are concerned about the security aspects.
answered Jan 8 '16 at 18:49
Eugen RieckEugen Rieck
10.9k22429
10.9k22429
I apologize, I meant VNC isn't an option as a matter of organization policy. But it's starting to sound like that might be the only way.
– AndroidNoobie
Jan 9 '16 at 9:23
Just use VNC and treat it as /dev/null. This makes the guest happy and doesn't stand in the way. Besides: If you manage to make your guest's network unusable (typo in /etc/network/interfaces), you have a way out.
– Eugen Rieck
Jan 9 '16 at 13:51
add a comment |
I apologize, I meant VNC isn't an option as a matter of organization policy. But it's starting to sound like that might be the only way.
– AndroidNoobie
Jan 9 '16 at 9:23
Just use VNC and treat it as /dev/null. This makes the guest happy and doesn't stand in the way. Besides: If you manage to make your guest's network unusable (typo in /etc/network/interfaces), you have a way out.
– Eugen Rieck
Jan 9 '16 at 13:51
I apologize, I meant VNC isn't an option as a matter of organization policy. But it's starting to sound like that might be the only way.
– AndroidNoobie
Jan 9 '16 at 9:23
I apologize, I meant VNC isn't an option as a matter of organization policy. But it's starting to sound like that might be the only way.
– AndroidNoobie
Jan 9 '16 at 9:23
Just use VNC and treat it as /dev/null. This makes the guest happy and doesn't stand in the way. Besides: If you manage to make your guest's network unusable (typo in /etc/network/interfaces), you have a way out.
– Eugen Rieck
Jan 9 '16 at 13:51
Just use VNC and treat it as /dev/null. This makes the guest happy and doesn't stand in the way. Besides: If you manage to make your guest's network unusable (typo in /etc/network/interfaces), you have a way out.
– Eugen Rieck
Jan 9 '16 at 13:51
add a comment |
you do not need VNC
just use -nographic and ssh tunnel (works for me, so it should work for you too)
-nographic means that qemu doesn't simulate a GPU, but if you ssh forward the screen anyway then it doesn't matter, less overhead than VNC too (not that it matters much)
you basically tell the guest programs that "hey, you need a screen? I have a screen for you" and then send all the screen data through ssh, instead of using a physical device on the guest
add a comment |
you do not need VNC
just use -nographic and ssh tunnel (works for me, so it should work for you too)
-nographic means that qemu doesn't simulate a GPU, but if you ssh forward the screen anyway then it doesn't matter, less overhead than VNC too (not that it matters much)
you basically tell the guest programs that "hey, you need a screen? I have a screen for you" and then send all the screen data through ssh, instead of using a physical device on the guest
add a comment |
you do not need VNC
just use -nographic and ssh tunnel (works for me, so it should work for you too)
-nographic means that qemu doesn't simulate a GPU, but if you ssh forward the screen anyway then it doesn't matter, less overhead than VNC too (not that it matters much)
you basically tell the guest programs that "hey, you need a screen? I have a screen for you" and then send all the screen data through ssh, instead of using a physical device on the guest
you do not need VNC
just use -nographic and ssh tunnel (works for me, so it should work for you too)
-nographic means that qemu doesn't simulate a GPU, but if you ssh forward the screen anyway then it doesn't matter, less overhead than VNC too (not that it matters much)
you basically tell the guest programs that "hey, you need a screen? I have a screen for you" and then send all the screen data through ssh, instead of using a physical device on the guest
answered Jan 19 at 15:02
user987296user987296
1
1
add a comment |
add a comment |
Thanks for contributing an answer to Super User!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1023636%2fneed-qemu-to-run-headless-on-host-but-still-forward-graphical-output-via-x11%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown