Need qemu to run headless on host, but still forward graphical output via x11












2















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.










share|improve this question





























    2















    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.










    share|improve this question



























      2












      2








      2








      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.










      share|improve this question
















      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






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Jan 9 '16 at 9:23







      AndroidNoobie

















      asked Jan 8 '16 at 18:00









      AndroidNoobieAndroidNoobie

      11324




      11324






















          2 Answers
          2






          active

          oldest

          votes


















          1














          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.






          share|improve this answer
























          • 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



















          0














          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






          share|improve this answer























            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
            });


            }
            });














            draft saved

            draft discarded


















            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









            1














            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.






            share|improve this answer
























            • 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
















            1














            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.






            share|improve this answer
























            • 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














            1












            1








            1







            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.






            share|improve this answer













            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.







            share|improve this answer












            share|improve this answer



            share|improve this answer










            answered Jan 8 '16 at 18:49









            Eugen RieckEugen Rieck

            11.1k22429




            11.1k22429













            • 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











            • 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













            0














            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






            share|improve this answer




























              0














              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






              share|improve this answer


























                0












                0








                0







                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






                share|improve this answer













                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







                share|improve this answer












                share|improve this answer



                share|improve this answer










                answered Jan 19 at 15:02









                user987296user987296

                1




                1






























                    draft saved

                    draft discarded




















































                    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.




                    draft saved


                    draft discarded














                    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





















































                    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







                    Popular posts from this blog

                    "Incorrect syntax near the keyword 'ON'. (on update cascade, on delete cascade,)

                    Alcedinidae

                    RAC Tourist Trophy