help with minimal vm guest setup

Forum Forums General Tips and Tricks help with minimal vm guest setup

  • This topic has 4 replies, 2 voices, and was last updated Jan 10-10:54 pm by imschmeg.
Viewing 5 posts - 1 through 5 (of 5 total)
  • Author
    Posts
  • #31560
    Member
    imschmeg

      I’m looking to tune an antiX 19 install as a VM guest, and make it as light-weight as possible (disk space, RAM and CPU) while still having good GUI support. The purpose is to have multiple of these vms running simultaneously, so host resource load is a big issue. I’m guessing this road is well traveled. I would appreciate any pointers to resources on this subject. Questions I have are: which services & daemons can be safely turned off, how to run without slim with single-user autologin, best WM to use, what large packages can be removed, is it best to start from antiX core and grow or antiX base and shrink, Qemu vs. VBox, KVM vs. Xen, etc.

      Thanks!

      #31570
      Anonymous
        Helpful
        Up
        0
        ::

        regarding disk space, search the forum for my past posts discussing “localepurge” and “dpkg-reconfigure locales”
        ( you might even go a step further, rm -rf /usr/share/man/* && rm -rf /usr/share/help/* )

        Although I would prefer to begin from “Full” and strip unwanted packages, base should be an equally good starting point. No, not core ~~ I expect you would trip over WAY too many landmines figuring out whatall is missing and needs to be installed in order for suchandsuch to work.

        fluxbox / IceWM / JWM are nearly identical (in the scheme of things) in terms of “lightweight-ness”.
        Removing unwanted pre-installed IceWM themes can shave a couple dozen MB. Stepping further, by uninstalling all but one of the preinstalled WMs would only free < 10MB, so I recommend “don’t bother” doing so.

        “how to run without slim with single-user autologin”
        No. Anyone asking this question is probably unprepared to deal with the potential consequences from doing so. SLiM adds what (20MB?) amount of session overhead ~~ if you need to run graphical sessions within each 50 VMs, tough love…

        “which services & daemons can be safely turned off”
        Same “no” as above. It’s your duty to research each service (sudo sysv-rc-conf) and decide what can / should be turned off for runlevel(s) XX on YOUR system, and across your VM instances, the choice may not be cookie-cutter identical. If you post a list, stating “I’m planning to turn off the following: X,y,Z. Will doing so break anything?” I might coachingly reply “howabout trying it, in a VM, and test the result?”

        “Qemu vs. VBox, KVM vs. Xen, etc.”

        .

        #31573
        Member
        imschmeg
          Helpful
          Up
          0
          ::

          regarding disk space, search the forum for my past posts discussing “localepurge” and “dpkg-reconfigure locales”
          ( you might even go a step further, rm -rf /usr/share/man/* && rm -rf /usr/share/help/* )

          Yes – did that first. I’ve used localpurge quite a bit. I do wish there was a fast way to configure it other than going through the ncurses menu to unselect everything except the few I want to keep…

          Although I would prefer to begin from “Full” and strip unwanted packages, base should be an equally good starting point. No, not core ~~ I expect you would trip over WAY too many landmines figuring out whatall is missing and needs to be installed in order for suchandsuch to work.

          Thanks – I will avoid core. Been having success with stripped base, but I have a slightly stripped full as well.

          fluxbox / IceWM / JWM are nearly identical (in the scheme of things) in terms of “lightweight-ness”.
          Removing unwanted pre-installed IceWM themes can shave a couple dozen MB. Stepping further, by uninstalling all but one of the preinstalled WMs would only free < 10MB, so I recommend “don’t bother” doing so.

          I am finding that is true with my experiments. I’m a bit surprised because some online sources such as this link suggested JWM < IceWM < Fluxbox. If nobody here is seeing such a difference, then I’m not going to waste my time trying to figure out why I’m not seeing any either.

          “how to run without slim with single-user autologin”
          No. Anyone asking this question is probably unprepared to deal with the potential consequences from doing so. SLiM adds what (20MB?) amount of session overhead ~~ if you need to run graphical sessions within each 50 VMs, tough love…

          I have tried running without slim, and dealt with the consequences. Not a big deal. But, haven’t yet combined it with auto-login…

          “which services & daemons can be safely turned off”
          Same “no” as above. It’s your duty to research each service (sudo sysv-rc-conf) and decide what can / should be turned off for runlevel(s) XX on YOUR system, and across your VM instances, the choice may not be cookie-cutter identical. If you post a list, stating “I’m planning to turn off the following: X,y,Z. Will doing so break anything?” I might coachingly reply “howabout trying it, in a VM, and test the result?”

          I am in the process of doing that. Takes a long time, though, to go through all the combinations, so I was hoping for some suggestions on what is likely to be easily tossable. Some are obvious – for instance, it is quite possible that nobody needs haveged – there’s sizeable debate on that. But these VMs don’t. Also, wpa-supplicant – VMs don’t have their own radios.

          BTW: If you’re reacting to the “Kick Me! I’m a NOOB!” sign taped to my back – I did NOT put that there!

          #31578
          Anonymous
            Helpful
            Up
            0
            ::

            “I do wish there was a fast way to configure it”

            echo "en_US.UTF-8 UTF-8" | sudo tee /etc/locale.gen
            LANG=C sudo dpkg-reconfigure --frontend=noninteractive locales
            LANG=C sudo update-locale LANG=en_US.UTF-8

            “this link suggested JWM < IceWM < Fluxbox”

            That’s the blog of the firejail author, IIRC. At the time of that article, what the versions of each WM had he tested? What versions of linked libraries were present on the system he used for benchmarking. JWM has gained some features (and has probably gained “weight”) since the date of that blog post.

            “quite possible that nobody needs haveged”

            If you omit it and discover a slow boot results, then re-enable it.
            Otherwise, yeah, its preinstalled presence just reflects the noble “a rising tide lifts all ships” doctrine.
            (aka the “suffrage of the many, for the benefit of the few rest” doctrine)

            glad to know that you care to consider what startup daemons might be pared. Really, the specs-n-usage of your system dictate the exact bare minimum needed. We’re micro-optimizing here, though. Collectively, the memory footprint of the preconfigured services is negligible. FYI, tips-n-tricks subforum has prior topics where additional suggestions have been offered.

            “Qemu vs. VBox, KVM vs. Xen, etc.”

            .

            .

            .

            #31580
            Member
            imschmeg
              Helpful
              Up
              0
              ::

              Collectively, the memory footprint of the preconfigured services is negligible.

              Yes, but also considering attack surface. One point to these tiny VMs is that they will run questionable things. So thanks for the CVE pointer. I’m doing the belt-and-suspenders thing by running the vms using only live ISOs, all in firejail as well. It’s a home-grown Qubes OS, but for older hardware. A tinfoil hat for those who can’t afford a helmet.

              Oh – and thanks for the locales hack (but really, whomever designed that ncurses UI should just add a “deselect all” button). I was keeping en_US ISO-8559-1 as well as UTF-8 – I guess I don’t need it?

            Viewing 5 posts - 1 through 5 (of 5 total)
            • You must be logged in to reply to this topic.