Announcement

Collapse
No announcement yet.

VirtualBox 6.1.14 Adds Linux 5.8 Kernel Support

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

  • VirtualBox 6.1.14 Adds Linux 5.8 Kernel Support

    Phoronix: VirtualBox 6.1.14 Adds Linux 5.8 Kernel Support

    Oracle has put out another VirtualBox 6.1 point release though making it notable this time around is support for the upstream Linux 5.8 kernel...

    http://www.phoronix.com/scan.php?pag...tualBox-6.1.14

  • #2
    What's more surprising is that vmware won't compile with 5.8 yet. Just tried.

    Comment


    • #3
      Finally!
      I can now upgrade the kernel.

      Comment


      • #4
        Originally posted by caligula View Post
        What's more surprising is that vmware won't compile with 5.8 yet. Just tried.

        https://github.com/mkubecek/vmware-host-modules/pull/72

        Comment


        • #5
          Ah, good old VirtualBox! Though I use KVM now I have very fond memories of VirtualBox, going way back to single core processors at a time when virtual CPU extensions didn't even exist. I'm glad Oracle didn't destroy it, and hope one day they'll branch out into QEMU/KVM and provide a better GUI interface than the spartan virt-manager.

          There's a big hole between simple things like virt-manager and complex ones like Proxmox, etc., which is why I've been working on my own system called Qemu Manager. It only has three working commands right now (Create, Run, and Help), but I had to create a CLI user interface that communicates with a daemon that communicates with a persistent service that controls and tracks virtual devices and files so it can dynamically bind and unbind VFIO devices, change VFIO/File permissions, assure multiple VMs don't use the same resources, etc.

          However the same machine can have multiple configurations, custom real-time priorities and nice values, etc. It's also independent of libvirt and systemd, though I currently use systemd to run services. However it doesn't use systemd sockets so it can run with any init system. And machines are simply created from an actual QEMU command line so you don't have to deal with all the complex XML stuff. In fact you can just look at the log from virt-manager and create machines from the command line it actually executes.

          And, of course, the whole thing is written in Bash so I'll never have to write it again! However I did finally have to upgrade my Bash infrastructure, and create my own arbitrary coprocess system to manage arbitrary coprocesses with independent stdin, stdout, and stderr. And the coprocesses have a few built in commands to read/write streams, flush streams, safely kill the process, etc. And some of the commands can be executed automatically on errors, etc. to simplify the management of coprocesses.

          But all that upgrading meant I had to go back and also upgrade my custom Wine Manager, which exposed a timing bug that I'm fixing right now. And I also spent some time refining my arbitrary multi-dimensional array system. But gosh darn it I've sworn to get back to Qemu Manager by Wednesday!
          Last edited by muncrief; 09-04-2020, 09:14 PM.

          Comment


          • #6
            Originally posted by muncrief View Post
            There's a big hole between simple things like virt-manager and complex ones like Proxmox, etc., which is why I've been working on my own system called Qemu Manager.
            Have you considered contributing code to (or forking) AQEMU?

            Comment


            • #7
              Originally posted by GizmoChicken View Post

              Have you considered contributing code to (or forking) AQEMU?
              Oh, I took a quick look and that looks very cool! It's also much more sophisticated than what I have at the moment. However I don't think I'd be much use because I spend about two thirds of my life in a state of extreme anxiety, and much of that time I literally have to lie in bed. A few times so long that I began to develop bed sores on my hips. In fact that's why I had to retire at the young age of 44. I went from working 16 hours days 7 days a week to barely being able to get up.

              But, though it was quite distressing at first, over the years I've learned to deal with it. And my goodness, after all the failed meds I've simply had to accept that it's just my fate, and try to be thankful for the incredibly productive years I had from the age of 12 to 44. I'm in my early 60s now and when I can get up I just do my own thing, and try not to work so hard that I drive myself back into a tizzy. But, unfortunately, now I'm either all on or all off.

              But hey, many people have it much worse, and I'm thankful that my Achilles heel, so far, is all in my head

              Heck, I don't even have arthritis, and can still grow my hair super long with nary a bald spot in sight!

              Good luck with your project though, it looks awesome and I wish you much success.

              Comment


              • #8
                Originally posted by muncrief View Post
                Good luck with your project though, it looks awesome and I wish you much success.
                Thanks much for the reply. But just to clarify, AQEMU is NOT my project.

                Rather, I too, prefer managing QEMU using an intuitive GUI without reliance on libvirt. For me, AQEMU already provides most all of the features that I want. I figured you may wish to extend AQEMU to include whatever features you need.

                Anyway, good luck with your project!

                Comment


                • #9
                  New Virtual version (the one which is not in the APT repo yet) have Python 2 dependencies injected.
                  So, I didn't install the latest stable built. I don't want to install Python 2 when I have Python 3 installed which is enough for me.

                  What do you think? (noob here)

                  Comment


                  • #10
                    muncrief To be fair, VirtualBox can use KVM as well. I don't see anything wrong with virt-manager, it's a powerful tool for managing VMs IMO, not sure if there's any complexity missing from it TBH.
                    That being said, using QEMU for fast VMs with PT is preferable simply because QEMU is usually the first to integrate new features at the cost of having constant command changes, and that is exact reason why virt-manager is created = to avoid constant QEMU changes potentially making VMs dysfunctional.
                    So generally, regardless of language used, when dealing with QEMU scripts, it is always wise to use as less complexity as possible.

                    Comment

                    Working...
                    X