From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: Seeking best-practice for managing guix-defined VMs Date: Tue, 16 Jan 2018 17:15:51 +0100 Message-ID: <87wp0h3hl4.fsf@gnu.org> References: <3bfa0bc6-8daa-f6d5-7ade-ec26e1329423@crazy-compilers.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:33621) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ebTu1-0008HD-MS for help-guix@gnu.org; Tue, 16 Jan 2018 11:15:58 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ebTty-0000u4-62 for help-guix@gnu.org; Tue, 16 Jan 2018 11:15:57 -0500 Received: from hera.aquilenet.fr ([185.233.100.1]:43456) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1ebTtx-0000tD-VK for help-guix@gnu.org; Tue, 16 Jan 2018 11:15:54 -0500 In-Reply-To: <3bfa0bc6-8daa-f6d5-7ade-ec26e1329423@crazy-compilers.com> (Hartmut Goebel's message of "Sun, 14 Jan 2018 19:51:59 +0100") List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-guix-bounces+gcggh-help-guix=m.gmane.org@gnu.org Sender: "Help-Guix" To: Hartmut Goebel Cc: help-guix Hello, Hartmut Goebel skribis: > I wonder about the best-practice for managing VMs built using `guix > system vm`. I=E2=80=99d recommend letting =E2=80=98guix system vm=E2=80=99 manage the s= tateless part of the VM, and if there=E2=80=99s any state, store it in a separate directory shar= ed with the host with =E2=80=9C--share=E2=80=9D. > 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")? =E2=80=98guix system=E2=80=99 won=E2=80=99t help you with that. You=E2=80= =99ll 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, =E2=80=98guix gc=E2=80=99 will delete them i= f 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 =E2=80=98guix system vm=E2=80=99 is fine. The key is to clearly se= parate the stateless part (software deployment) from state (secrets, databases, etc. that your applications may need.) HTH, Ludo=E2=80=99.