OpenBSD Journal

Setting up your own internal network w/ qemu.

Contributed by merdely on from the its-a-virtual-world dept.

Paul Irofti writes about how he's using Qemu on OpenBSD:

Many times I found myself wanting to test something on a different arch or look at what a new OS brings (specially the hobbyist ones announced now and then on OSNews) or simply test some network configurations w/o affecting the existing one. So I started looking at virtual emulators and such.

After some documentation and searching qemu seemed to be the best to fit my needs and closest to my philosophy. In this article I'll present a way to quickly build a virtual network environment with OpenBSD as host.

Paul describes how to get Qemu installed on OpenBSD (well, "pkg_add qemu"), how to set up a drive image and how to install an OS on the guest system. Then he explains how to configure networking between the OpenBSD host and the guest using the built-in /etc/qemu-ifup script functionality. The script configures a bridge between a real interface on the host and a tun interface the guest system binds to. Finally, he describes configuring pf to allow the guest Qemu system to communicate beyond the OpenBSD host.

Read the full article on the NewOrder Computer Security and Networking Portal.

(Comments are closed)

Comments

  1. By Anonymous Coward (24.89.228.211) on

    QEMU is very impressive. The only problem I've found (I'm not running the latest version port though, so maybe this has been fixed) is that the OpenBSD OSS audio support does not allow you to hook up a microphone under QEMU (seems it that QEMU then tries to lock the audio device separately for input and output and fails (thus no Teamspeak, or similar).

    I'm running Windows 98 as a guest OS on a mere Pentium 3 450 MHz OpenBSD host ... it can't play and mp3 but it boots and runs adequately fast for the occasional check of a web page against IE.

    Comments

    1. By Anonymous Coward (24.22.214.92) on

      > QEMU is very impressive. The only problem I've found (I'm not running the latest version port though, so maybe this has been fixed) is that the OpenBSD OSS audio support does not allow you to hook up a microphone under QEMU (seems it that QEMU then tries to lock the audio device separately for input and output and fails (thus no Teamspeak, or similar).
      >
      > I'm running Windows 98 as a guest OS on a mere Pentium 3 450 MHz OpenBSD host ... it can't play and mp3 but it boots and runs adequately fast for the occasional check of a web page against IE.

      In my experience, Windows 2000 is *much* faster than Win98 is, and makes a great alternative in QEMU. It supports IE6 as well, so for the casual web developer, if you happen to have Win2000, I'd recommend that instead.

  2. By Lennie (84.246.2.129) on

    A Qemu virtual machine can even have several network interfaces.

    That combined with vde_switch & friends [0] you can build a pretty complicated virtual network of qemu-virtual machines, for testing
    network protocols & configurations.

    I've used it for running virtual OpenBSD's on my Linux desktop

    You can even use VLAN's or Spanning Tree Protocol.

    *NOTE* I've not tested vde_switch on non-virtual OpenBSD yet. So
    I don't know how well that works.

    [0] http://wiki.virtualsquare.org/index.php/VDE

  3. By Alvaro (15.227.217.77) on

    what about kqemu?? I think it would be wonderful has a little acceleration on qemu. Is there any reason for kqemu not to be in ports?

    Comments

    1. By moo (84.135.112.14) on

      > what about kqemu?? I think it would be wonderful has a little acceleration on qemu. Is there any reason for kqemu not to be in ports?

      kqemu is, as the name suggest, a linux kernel module that hooks up some kernel thingys to make qemu 'faster'. yes, you could provide an kqemu-port but it would be pretty useless.

      Comments

      1. By njr (njr) on

        Do you honestly think it would be useless to have the emulated
        code running natively and much faster on the host CPU? I think
        most people using x86 hardware would find it very useful.

        > kqemu is, as the name suggest, a linux kernel module that hooks
        > up some kernel thingys to make qemu 'faster'. yes, you could
        > provide an kqemu-port but it would be pretty useless.
        >
        > > what about kqemu?? I think it would be wonderful has a
        > > little acceleration on qemu. Is there any reason for
        > > kqemu not to be in ports?


        Comments

        1. By Anonymous Coward (128.171.90.200) on

          > Do you honestly think it would be useless to have the emulated
          > code running natively and much faster on the host CPU? I think
          > most people using x86 hardware would find it very useful.

          I think it would be completely useless using OpenBSD if you are prepared to run an emulator like qemu in kernel space.

          If you have x86 hardware, it is a lot faster just to install onto the machine itself rather than using an emulator.

          Comments

          1. By njr (220.34.250.187) on

            > I think it would be completely useless using OpenBSD if you
            > are prepared to run an emulator like qemu in kernel space.

            I'd agree with you, if I didn't think OpenBSD was superior to alternatives in areas other than those directly affected by using an emulator in kernel space.

            Comments

            1. By Anonymous Coward (128.171.90.200) on

              > I'd agree with you, if I didn't think OpenBSD was superior to alternatives in areas other than those directly affected by using an emulator in kernel space.

              put your emulator in kernel space and you lose the advantage

              Comments

              1. By njr (220.34.250.187) on

                > put your emulator in kernel space and you lose the advantage

                As I said, I don't agree that running an emulator in kernel space defeats all the advantages of using OpenBSD.

                Just for the sake of the discussion imagine someone was used to running OpenBSD, they'd been using it for years, they knew how to use it, all the machines in their organisation ran it and more importantly they believed in the philosophy behind it. Now they want to run an emulator with reasonable speed. Do you expect them to install another operating system just because running that emulator on OpenBSD happens to defeat one of the primary goals of the project?

                I don't see how it's possible to call an optional port "completely useless" when clearly it would be useful to some, even if it's at the cost of security.

                At best you could call it unwise to make such a port available, but then you're assuming users are clueless.

                Addressing the other point you made in your first post, there are diagnostic things you can do in an emulator that aren't possible on commodity hardware and some users don't have hardware to spare. So it's not always possible to just install it on the machine itself.

                I don't agree that a port of kqemu is completely useless and I see no reason to discourage it.

                Comments

                1. By Anonymous Coward (128.171.90.200) on

                  Quite frankly, we all have the freedom to be as big a fool as we like.

        2. By moo (84.135.112.14) on

          > Do you honestly think it would be useless to have the emulated
          > code running natively and much faster on the host CPU?

          No, but that's not what I said.

          Comments

          1. By njr (220.34.250.187) on

            > No, but that's not what I said.

            I misunderstood what you meant by "provide an kqemu-port". I thought this meant, provide a port of kqemu to OpenBSD.

      2. By minusf (195.168.92.92) on 

        > kqemu is, as the name suggest, a linux kernel module that hooks
> up some kernel thingys to make qemu 'faster'. yes, you could provide
> an kqemu-port but it would be pretty useless.

doesn't freebsd has kqemu?...

    2. By Anonymous Coward (70.173.172.228) on

      > what about kqemu?? I think it would be wonderful has a little acceleration on qemu. Is there any reason for kqemu not to be in ports?

      mainly because no-one has written a kqemu-openbsd.c yet. It would involve knowing how to write openbsd lkm(4)s (ioctls, some kernel internals) as well as same for (freebsd|linux) depending on which code you use as a base. The speed increase from running it may or may not make it worth your time to port it (it would basically only help when emulating a certain cpu on that same class of cpu and is limited to x86 and x86_64/amd64 only iirc).

  4. By Anonymous Coward (63.225.103.47) on

    Mike,

    Thanks for the link--it's nice to read about host virtualization options for an OS that has a limited few.

    Comments

    1. By Anonymous Coward (70.173.172.228) on

      > Mike,
      >
      > Thanks for the link--it's nice to read about host virtualization options for an OS that has a limited few.

      vaguely off-topic, but what has happened with the openbsd-xen project(s)?

      Comments

      1. By Anonymous Coward (64.41.122.5) on

        > > Mike,
        > >
        > > Thanks for the link--it's nice to read about host virtualization options for an OS that has a limited few.
        >
        > vaguely off-topic, but what has happened with the openbsd-xen project(s)?

        I'm currently running OpenBSD 4.1 as a Xen guest on AMD64. It's using Xen's hardware virtualization functionality so the host CPU has to support that feature. I never spent the time to get OpenBSD working in the non-hardware virtual environment--I ran into some issues at the time which was several months ago.

        Comments

        1. By dingo (70.8.120.102) on

          > > vaguely off-topic, but what has happened with the openbsd-xen project(s)?
          >
          > I'm currently running OpenBSD 4.1 as a Xen guest on AMD64. It's using Xen's hardware virtualization functionality so the host CPU has to support that feature. I never spent the time to get OpenBSD working in the non-hardware virtual environment--I ran into some issues at the time which was several months ago.

          I can second openbsd is good on HVM -- building patch branch now w/o issues. Debian running as the host.

          As for the paravirtualization, the person who had the Xen branch of OpenBSD in development was using something strange and non-cvs, was down all the time, and I couldn't get it to work either. He has a blog and hasn't spoken of it in a long while, and his commits seem trivial. Almost ended up using netbsd or debian for my needs until HVM support came out. Thank god cause I needed an ipsec gateway and racoon is a f'cking nightmare.

          Biggest downside so far is the use of ne(3) as ethernet device...

  5. By njr (njr) on

    For a while I was running OpenBSD in QEMU on an OpenBSD host with the internet facing physical interface bridged to QEMU. I ran pppoe in the emulated machine and used it for ssh, web serving and NAT. The performance wasn't great as it was on a slow mini-itx Via machine. Things improved when I did the pppoe on the adsl router instead.

    I often wondered if the CPU that QEMU emulated supported the range-of-execution feature used to do w^x on x86.

  6. By Anonymous Coward (132.194.76.32) on

    Along the same theme, what is the opinion of using some sort of VM machine and switching between say OpenBSD, and Windows when needed, versus dual booting between both? Does using a VM setup bring limits that dual booting doesn't have?

    Comments

    1. By SolarCatcher (81.241.250.213) on

      As far as I know there are limitis in accessing hardware from within the guest OS. USB peripherals are an example of this. For more information on this look for example into the qemu FAQs.

Latest Articles

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]