Announcement

Collapse
No announcement yet.

OpenBSD Is Getting Its Own Native Hypervisor

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • OpenBSD Is Getting Its Own Native Hypervisor

    Phoronix: OpenBSD Is Getting Its Own Native Hypervisor

    The OpenBSD Foundation has been funding work on a project to provide OpenBSD with its own, native hypervisor...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    This is an example of the double standard that's happening in the BSD world today. You have OpenBSD fscks claiming they don't do visualization because it's insecurity and "bad practice" yet now they adding visualization IN 2016. Not only is it hypocritical, it's long over due and everyone has moved on.

    The worst part is this tries to reinvent the there's wheel there's already Bhyve from FreeBSD that you can port over easily. Yes Bhyve is crap and no one uses it but that's what all BSDs and in-particular OpenBSD is about. So Bhyve is perfect for OpenBSD. Why create your own virtual machine.

    Comment


    • #3
      Originally posted by endman View Post
      This is an example of the double standard that's happening in the BSD world today. You have OpenBSD fscks claiming they don't do visualization because it's insecurity and "bad practice" yet now they adding visualization IN 2016.
      It's virtualization, not visualization. Also, I remember that discussion; was started for a random guy claiming that virtualization improves security. They never say OpenBSD will never support hardware virtualization, just that is insecure. In fact, OpenBSD support guest virtualization since ages.

      Originally posted by endman View Post
      The worst part is this tries to reinvent the there's wheel there's already Bhyve from FreeBSD that you can port over easily.
      The article explains why.
      Last edited by rmiller; 31 August 2015, 07:27 PM.

      Comment


      • #4
        Originally posted by rmiller View Post

        It's virtualization, not visualization. Also, I remember that discussion; was started for a random guy claiming that virtualization improves security. They never say OpenBSD will never support hardware virtualization, just that is insecure. In fact, OpenBSD support guest virtualization since ages.



        The article explains why.
        Ignore him. He's a troll and he hasn't even been half-assing his trolling as of late.

        Comment


        • #5
          Originally posted by mlarkin
          TL;DR - a native hypervisor is coming. stay tuned.
          <sign> Another BSD ?originated? shit that no one will use.</sign> Ever heard of bhyve?

          Originally posted by mlarkin
          For the last few months, I've been working on a hypervisor for OpenBSD. The idea for this started a few years ago, and after playing around with it from time to time, things really started to take shape around the time of the Brisbane hackathon earlier this year.
          Aka. Screwing around not knowing what you are actually doing.

          Originally posted by mlarkin
          As development accelerated, the OpenBSD Foundation generously offered to fund the project so that I could focus on it in more earnest.
          Too bad that fund will dry up before you finish cause OpenBSD?s in financial collapse (http://bsd.slashdot.org/story/14/01/...rtfall-in-2014 and http://bsd.slashdot.org/story/14/01/...rtfall-in-2014)

          Originally posted by mlarkin
          At this point, I think I've made sufficient progress that a public announcement is in order.

          Presently, the vmm code I've built is capable of launching a kernel and asking for the root filesystem; it doesn't do much more than that for now.
          You call this sufficient progress:

          Code:
          # cu -l /dev/ttyp0
          exit save va/pa  0xfffff000bcff000 0xbcff000
          exit load va/pa  0xfffff000bd1e000 0xbd1e000
          entry load va/pa 0xffffff000bd2c000 0xbd2c000
          vmd: new vm with id 1 created
          loading 64 bit kernel
          warning: bcopy during ELF kernel load not supported
          warning: bcopy during ELF kernel load not supported
          mark[start] = 0x1000000
          mark[entry] = 0x1000160
          mark[nsym] = 0x1
          mark[sym] = 0x1939000
          mark[end] = 0x1a1de00
          mark[random] = 0x18a4000
          mark[erandom] = 0x18a6408
          vmd: all vcpu run threads for vm 3 launched
          vcpu_run_vmx: yielding the cpu
          vmd: waiting on thread 0
          vcpu_run_vmx: yielding the cpu
          vcpu_run_vmx: yielding the cpu
          loading 0x1a44000-0x4000000 (0x1a44-0x4000)
          loading 0x100000-0x1000000
          avail_start = 0x26000
          avail_end = 0x4000000
          First_avail = 0x1a44000
          [ bsd ELF symbol table not valid: bad magic ]
          [ no symbol table formats found ]
          Copyright (c) 1982, 1986, 1989, 1991, 1993
                  The Regents of the University of California.  All rights reserved.
          Copyright (c) 1995-2015 OpenBSD. All rights reserved.  http://www.OpenBSD.org
           
          OpenBSD 5.8-current (GENERIC) #204: Mon Aug 31 01:13:40 PDT 2015
              [email protected]:/export/bin/src/OpenBSD/vmm/src/sys/arch/amd64/compile/GENERIC
          vmd: i8253 PIT: 16 bit counter I/O not supported
          RTC BIOS diagnostic error ff
          real mem = 50331648 (48MB)
          avail mem = 45101056 (43MB)
          mpath0 at root
          scsibus0 at mpath0: 256 targets
          mainbus0 at root
          bios0 at mainbus0
          acpi at bios0 not configured
          cpu0 at mainbus0: (uniprocessor)
          cpu0: Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz
          cpu0: FPU,VME,DE,PSE,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH
          ,DS,MMX,FXSR,SSE,SSE2,SS,HTT,PBE,SSE3,PCLMUL,DTES64,DS-CPL,SSSE3,CX16,xTPR,PCID,
          SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,AVX,F16C,RDRAND,HV,ITSC,FSGSBASE,SMEP,E
          RMS
          pvbus0 at mainbus0: OpenBSD
          vmx_handle_cpuid: unsupported rax=0x40000100
          pci0 at mainbus0 bus 0
          isa0 at mainbus0
          isadma0 at isa0
          com0 at isa0 port 0x3f8/8 irq 4: ns8250, no fifo
          com0: console
          vmm at mainbus0 not configured
          vmx_handle_cr: mov to cr8 @ ffffffff8131854a
          nvram: invalid checksum
          vscsi0 at root
          scsibus1 at vscsi0: 256 targets
          softraid0 at root
          scsibus2 at softraid0: 256 targets
          root device:
          <hangs>
          Most public announcements happen when the software is working in some form or another.

          Originally posted by mlarkin
          I've also reached the point where I think other developers can step in and help out as much of the gooey bits in the core of the vmm are functioning the way I want.
          What developers? All there is, is just a bunch of lunatics playing software engineer and inventing the wheel and making crappier versions of things that already exist.

          Originally posted by mlarkin
          However, getting to this point invovled building most of the scaffolding needed to finish the rest, and like I stated before, more people can now more easily help with what's left (basically the virtio(4) emulation for disks and network interfaces).
          Sounds like you?ve given up and what someone else to pick up the pieces. Also, none of your fellow BSD nuts will help you, they believe virtualization is bad.

          Originally posted by mlarkin
          One might ask - why not port one of the other hypervisors out there instead of rolling your own from scratch? Fair question. However, for various technical reasons, choosing to port an existing vmm just didn't make a whole lot of sense. For example, I've been baking in support for things that the other implementations don't care about (namely i386 support, shadow paging, nested virtualization, support for legacy peripherals, etc) and trying to backfit support for those things into another hypervisor would probably have been just as hard as building it from the ground up.

          Q. Yuck, i386?
          A. Yes. It helps find bugs. And I urge you to review my last dozen or so commits to i386 for another reason.
          Yes, it helps find bugs that are not relevant anymore many bugs in the i386 version that no one uses but it also adds bugs to the amd64 version because the code has to be more complicated to support an architecture that no one uses.

          Originally posted by mlarkin
          The inevitable questions:
          Yes, like is there anything better in life that you could do other than this?

          Originally posted by mlarkin
          Q. What OSes can I run?
          A. To start, OSes that support virtio-based devices (most of the CPU goo is done and is basically the same across most OSes once you get that part finished). Later, we'll see if we can expose a place for qemu to attach (maybe mimic KVM) to run legacy OSes or OSes that require BIOS/UEFI boot support. There is no legacy-free mandate in this vmm.
          Realistically, this will end up running only OpenBSD i386 for a long time. Maybe FreeBSD i386 in 2019 but by then other virtualisation options will be way ahead.

          Originally posted by mlarkin
          Q. When will it be ready?
          A. Hard to say. I hope by the end of October, but no promises. A lot also depends on how much help I get writing some of the virtio backends.
          Haha, nice joke. It?ll be ready in 2017 (minimum).

          Originally posted by mlarkin
          Q. What will be the CPU requirements?
          A. Any AMD or Intel CPU that supports hardware virtualization (SVM for AMD, and VMX for Intel). For those CPUs that don't support RVI or EPT, we'll use shadow paging.
          This reminds me, the user experience of is will be far worse than Bhyve because OpenBSD has terrible SMP and memory. The whole system will need a CPU purchasable only from Dior and Quintessentially to be usable.

          Originally posted by mlarkin
          Q. What will be the OS requirements?
          A. The core tools (vmd(8) and vmmctl(8)) and the main vmm (vmm(4)) will be built in to base, on i386 and amd64. This should be sufficient to run virtio based guests without any additional software requirements.
          Code:
           
           # vmmctl -e  
           cpu0: entered VMM mode   
           # vmmctl -S -c openbsd_amd64.vmrc  
           /dev/ttyp0   
           # cu -l /dev/ttyp0
          Xen hypervisor and KVM is far easier to use then this shit.

          Originally posted by mlarkin
          Q. How can I help?
          A. I would have likely had no time to work on this project for the past few months had it not been for the generous sponsorship of the OpenBSD Foundation. Your donations made that possible, and other projects like this. So, you can help by donating. If you think a hypervisor in OpenBSD is something you'd like to take advantage of, I urge you to go make a donation right now.

          Like I want to give money to help create code that will end up in proprietary software, I rather give my money to Donald Trump to fund his campaign than give money to a BSD permissive license pile of crap.

          endman out.

          Comment


          • #6
            Originally posted by endman View Post
            endman out.
            Dreams come true.

            Comment


            • #7
              Trolls aside (I'm talking to you endman), it does seem weird that OpenBSD, with its scarce development resources write their own VMM solution, including, I assume the FE, instead of porting another VMM solution (E.g. bhyve). The i386 / nested virtualization arguments does look a bit scarce.

              Even though I rarely play with OpenBSD (being a Linux guy) I do hope they'll manage to pull it off.

              - Gilboa
              oVirt-HV1: Intel S2600C0, 2xE5-2658V2, 128GB, 8x2TB, 4x480GB SSD, GTX1080 (to-VM), Dell U3219Q, U2415, U2412M.
              oVirt-HV2: Intel S2400GP2, 2xE5-2448L, 120GB, 8x2TB, 4x480GB SSD, GTX730 (to-VM).
              oVirt-HV3: Gigabyte B85M-HD3, E3-1245V3, 32GB, 4x1TB, 2x480GB SSD, GTX980 (to-VM).
              Devel-2: Asus H110M-K, i5-6500, 16GB, 3x1TB + 128GB-SSD, F33.

              Comment


              • #8
                Originally posted by gilboa View Post
                Trolls aside (I'm talking to you endman), it does seem weird that OpenBSD, with its scarce development resources write their own VMM solution, including, I assume the FE, instead of porting another VMM solution (E.g. bhyve).
                That's more reason why they shouldn't be wasting time on this crap not that they are already wasting time by being involved with OpenBSD. BSD is already so fragmented. First FreeBSD got bhyve will is crap, then they port KVM which is great on Linux but crap on BSD. Now rather then adopting KVM or atleast bhyve, openBSD decides to make their own hypervisor with no name.

                BSD's always contribute to fragmentation in contrast to Lennart Poettering and systemd which encourages standardization. You can see the different. Linux is one of the most standardized group of distros around (save for a few) while BSD is the epitamy of fragmentation. Looks like this saying is coming truth, the number of BSD users and BSD distros are converging. When that ratio hits 1:1, it's all over.

                The i386 / nested virtualization arguments does look a bit scarce.
                There's a reason for that. x86-64 has rendered i386 redundant. Also x86-64 can emulate i386. You can run an i386 OS on an x86-64 VM or hardware. This excuse by OpenBSD is completely baseless.

                Even though I rarely play with OpenBSD (being a Linux guy) I do hope they'll manage to pull it off.

                - Gilboa
                Good thing you rarely play with OpenBSD and best of all that you are a Linux guy. But I rather they fail miserably as every BSD related software beings the world more misery.

                Comment


                • #9
                  Originally posted by jake_lesser View Post
                  There's a reason for that. x86-64 has rendered i386 redundant. Also x86-64 can emulate i386. You can run an i386 OS on an x86-64 VM or hardware. This excuse by OpenBSD is completely baseless.
                  A x86-64 VM doesn't run on a i386 CPU (Intel Atom Z5xx and N2xx series dont sopport x86-64).

                  Comment


                  • #10
                    Originally posted by nasyt View Post

                    A x86-64 VM doesn't run on a i386 CPU (Intel Atom Z5xx and N2xx series dont sopport x86-64).
                    I said i386 can run on x86-64 with or without a VM. I also said that i386 can also run on an x86-64 VM. Stop claiming things I didn't say.

                    Comment

                    Working...
                    X