[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Seeking best-practice for managing guix-defined VMs

From: Hartmut Goebel
Subject: Seeking best-practice for managing guix-defined VMs
Date: Sun, 14 Jan 2018 19:51:59 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2


I wonder about the best-practice for managing VMs built using `guix
system vm`.

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")?

* Over time, the store will fill up with `` 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)?

* 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.

* Is using `guix system vm` the wrong approach at all? Should I better
use `vm-image` or `container`?

Hartmut Goebel

| Hartmut Goebel          | address@hidden               |
| | compilers which you thought are impossible |

reply via email to

[Prev in Thread] Current Thread [Next in Thread]