OpenBSD Journal

vmm enabled

Contributed by phessler on from the turtles-all-the-way-down dept.

With a small commit, OpenBSD now has a hypervisor and virtualization in-tree. This has been a lot of hard work by Mike Larkin, Reyk Flöter, and many others.

VMM requires certain hardware features (Intel Nehalem or later, and virtualization enabled in the BIOS) in order to provide VM services, and currently only supports OpenBSD guests. 

CVSROOT:	/cvs
Module name:	src
Changes by:	mlarkin@cvs.openbsd.org	2016/10/12 02:30:26

Modified files:
	sys/arch/amd64/conf: GENERIC 

Log message:
enable vmm

This has been enabled in snapshots for a week, so your favourite mirror is already ready for you to upgrade. Of course, please report any bugs you run into.

This work was partially sponsored by The OpenBSD Foundation, and if you like it, please donate or bid on the signed cd set.

(Comments are closed)

Comments

  1. By Renaud (91.183.56.64) on

    My question will maybe look a little bit stupid, but is it limited to Intel hosts or will it also work with AMD hosts (with AMD-V enabled)?

    Comments

    1. By phessler (phessler) on http://www.openbsdfoundation.org/donations.html

      > My question will maybe look a little bit stupid, but is it limited to Intel hosts or will it also work with AMD hosts (with AMD-V enabled)?

      Currently this is limited to Intel hosts. We would like to get AMD also supported, but that requires some more work.

      Comments

      1. By Damien Couderc (91.135.176.215) on

        > > My question will maybe look a little bit stupid, but is it limited to Intel hosts or will it also work with AMD hosts (with AMD-V enabled)?
        >
        > Currently this is limited to Intel hosts. We would like to get AMD also supported, but that requires some more work.

        Arg, this should be mentioned in the man page :-(

        Comments

        1. By Anonymous Coward (73.97.108.7) on

          > > > My question will maybe look a little bit stupid, but is it limited to Intel hosts or will it also work with AMD hosts (with AMD-V enabled)?
          > >
          > > Currently this is limited to Intel hosts. We would like to get AMD also supported, but that requires some more work.
          >
          > Arg, this should be mentioned in the man page :-(
          >

          Diff or gtfo

          Comments

          1. By Damien Couderc (91.135.176.215) on

            > > > > My question will maybe look a little bit stupid, but is it limited to Intel hosts or will it also work with AMD hosts (with AMD-V enabled)?
            > > >
            > > > Currently this is limited to Intel hosts. We would like to get AMD also supported, but that requires some more work.
            > >
            > > Arg, this should be mentioned in the man page :-(
            > >
            >
            > Diff or gtfo

            This is just ridiculous, come back with a name and some commits and we could maybe have a real discussion.

          2. By BSDfan (91.241.33.66) on

            > > > > My question will maybe look a little bit stupid, but is it limited to Intel hosts or will it also work with AMD hosts (with AMD-V enabled)?
            > > >
            > > > Currently this is limited to Intel hosts. We would like to get AMD also supported, but that requires some more work.
            > >
            > > Arg, this should be mentioned in the man page :-(
            > >
            >
            > Diff or gtfo

            He he, another typical answer from OpenBSD folks...

            Comments

            1. By sthen (82.68.199.128) on http://junkpile.org/sthen-time.png

              > > > > > My question will maybe look a little bit stupid, but is it limited to Intel hosts or will it also work with AMD hosts (with AMD-V enabled)?
              > > > >
              > > > > Currently this is limited to Intel hosts. We would like to get AMD also supported, but that requires some more work.
              > > >
              > > > Arg, this should be mentioned in the man page :-(
              > > >
              > >
              > > Diff or gtfo
              >
              > He he, another typical answer from OpenBSD folks...

              No, it's another useless waste-of-space needlessly inflammatory response from someone who didn't think before they posted.

          3. By Anonymous Cowboy (178.17.170.238) on

            > > > > My question will maybe look a little bit stupid, but is it limited to Intel hosts or will it also work with AMD hosts (with AMD-V enabled)?
            > > >
            > > > Currently this is limited to Intel hosts. We would like to get AMD also supported, but that requires some more work.
            > >
            > > Arg, this should be mentioned in the man page :-(
            > >
            >
            > Diff or gtfo

            Go fuck yourself. This is why people are discouraged from the openbsd community; because of community-member-wannabes like you prancing about thinking you know how to handle the world.

  3. By Shane J Pearson (49.255.252.254) on

    Wow, this is really exciting!

    And just one example of why I think it is so important to support this project which continues to develop solid, secure, well built software with the "do it properly" stance.

    I'm very much looking forward to how I might be able to use this for some OpenBSD honeypots.

  4. By Shane J Pearson (49.255.252.254) on

    The more I think about the possibilities with vmm, the more excited I get.

    So I could run OpenBSD on some bare metal just configured with a management interface and then within that an instance of an OpenBSD firewall VM bridged to the other physical interfaces?

    The benefits being that I could so easily back up the VM, prior to making config changes, patching, upgrades, etc. Or even very quickly restore a VM to other hardware in the event of physical failure.

    Stuff I do now with other virtualisation systems, but with OpenBSD at the core and no need for virtualising a framebuffer I don't need? Awesome.

    Comments

    1. By Edward Ahlsen-Girard (Ed) on

      > The more I think about the possibilities with vmm, the more excited I get.
      >
      > So I could run OpenBSD on some bare metal just configured with a management interface and then within that an instance of an OpenBSD firewall VM bridged to the other physical interfaces?
      >

      What's protecting the OpenBSD on bare metal?

      Every packet a virtual sees has already been through the host's network stack.

      Comments

      1. By Kramse (2a02:2190:f000:cf0f:21fb:ce7a:6f9f:2825) on

        > > The more I think about the possibilities with vmm, the more excited I get.
        > >
        > > So I could run OpenBSD on some bare metal just configured with a management interface and then within that an instance of an OpenBSD firewall VM bridged to the other physical interfaces?
        > >
        >
        > What's protecting the OpenBSD on bare metal?
        >
        > Every packet a virtual sees has already been through the host's network stack.
        >

        No, while I haven't looked specifically in this implementation.

        In general with virtualisation the packets are often bridged into the guest, or in some cases the actual hardware is mapped in. So the packet touch very little of the host network stack if at all. The idea is valid as said above.

        Ultimately you can go down the path of Qubes OS, which has NO networking in the Xen dom0 and one VM sys-net handles networking, with a sys-firewall behind it doing - yeah firewalling.

        On Mac OS X when I looked the driver for VMware virtualisation was injecting the packets when sending from VMs in bridged mode, and catching/removing them from input queue when receiving the ones for the virtual machine MAC address.

        Comments

        1. By Edward Ahlsen-Girard (Ed) on

          > > > The more I think about the possibilities with vmm, the more excited I get.
          > > >
          > > > So I could run OpenBSD on some bare metal just configured with a management interface and then within that an instance of an OpenBSD firewall VM bridged to the other physical interfaces?
          > > >
          > >
          > > What's protecting the OpenBSD on bare metal?
          > >
          > > Every packet a virtual sees has already been through the host's network stack.
          > >
          >
          > No, while I haven't looked specifically in this implementation.
          >
          > In general with virtualisation the packets are often bridged into the guest, or in some cases the actual hardware is mapped in. So the packet touch very little of the host network stack if at all. The idea is valid as said above.
          >
          > Ultimately you can go down the path of Qubes OS, which has NO networking in the Xen dom0 and one VM sys-net handles networking, with a sys-firewall behind it doing - yeah firewalling.
          >
          > On Mac OS X when I looked the driver for VMware virtualisation was injecting the packets when sending from VMs in bridged mode, and catching/removing them from input queue when receiving the ones for the virtual machine MAC address.

          Thanks, this is good to know.

      2. By Anonymoose Cow (185.38.14.171) on

        > What's protecting the OpenBSD on bare metal?

        A disused lavatory with a sign on the door saying Beware of the Leopard.

  5. By Anonymous Coward (24.22.0.104) on

    How's nested VT-x coming?

    Comments

    1. By brynet (Brynet) on https://brynet.biz.tm/

      > How's nested VT-x coming?

      https://twitter.com/mlarkin2012/status/789363554419736576

      Pretty good I'd say.

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.]