[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Seeking best-practice for managing guix-defined VMs
From: |
Ludovic Courtès |
Subject: |
Re: Seeking best-practice for managing guix-defined VMs |
Date: |
Tue, 16 Jan 2018 17:15:51 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) |
Hello,
Hartmut Goebel <address@hidden> skribis:
> I wonder about the best-practice for managing VMs built using `guix
> system vm`.
I’d recommend letting ‘guix system vm’ manage the stateless part of the
VM, and if there’s any state, store it in a separate directory shared
with the host with “--share”.
> My idea is to have the system-configuration on the (foreign distro) host
> and build and run VMs using `guix system vm`. Background is that for
> some reasons I can not use GuixSD on the host, but wont to use guix for
> managing the actual work-horses.
>
> * For specifying the parameters of the host-side of the VM-emulation,
> and for starting the VM with the appropriate parameters, I can add a
> wrapper shell-script. Is there a better way than a shell-script?
>
> * When updating the config, the currently running VM needs to be shut
> down. What are good ways to handle this? How to notice, which is the
> correct VM to shut down (this one's "predecissor")?
‘guix system’ won’t help you with that. You’ll have to do your own
bookkeeping I guess.
> * Over time, the store will fill up with `xxx-run-vm.sh` scripts. Will
> these be garbage-collected? (I assume not.) What are good ways to keep
> track of scripts and discard those no longer needed (and garbage-collect)?
Like everything in /gnu/store, ‘guix gc’ will delete them if they are
unused and unreachable.
> * How to handle "secrets", which need to go into the machine? Obviously
> it's not a good idea to have them in a system-declaration. OTO the VM's
> disk gets discarded with the next system generation.
Everything Guix manages ends up world-readable in /gnu/store. So you
need an out-of-band channel for secrets, such as --share.
> * Is using `guix system vm` the wrong approach at all? Should I better
> use `vm-image` or `container`?
I think ‘guix system vm’ is fine. The key is to clearly separate the
stateless part (software deployment) from state (secrets, databases,
etc. that your applications may need.)
HTH,
Ludo’.