Seeking best-practice for managing guix-defined VMs

Seeking best-practice for managing guix-defined VMs

[Hartmut Goebel]

Hi,

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

* 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`?

-- 
Regards
Hartmut Goebel

| Hartmut Goebel          | h.goebel@crazy-compilers.com               |
| www.crazy-compilers.com | compilers which you thought are impossible |

Re: Seeking best-practice for managing guix-defined VMs

[Marius Bakke]

[-- Attachment #1: Type: text/plain, Size: 657 bytes --]

Hartmut Goebel <h.goebel@crazy-compilers.com> writes:

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

This is fairly tangential and probably overkill, but I use Ganeti[0]
with "ganeti-instance-guix"[1].  That will copy each `guix system vm` to
the configured storage backend, so store items can be garbage collected.
Updating can be done with `gnt-instance reinstall vm-name`.

Ganeti is a distributed virtual machine management system à la Openstack
(though much simpler, and less buggy), but works great on a single host.

[0] http://www.ganeti.org/
[1] https://github.com/mbakke/ganeti-instance-guix

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Seeking best-practice for managing guix-defined VMs

[myglc2]

On 01/14/2018 at 19:51 Hartmut Goebel writes:

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

I doubt this is best practice, but I have been using a bash script to
build, commission, and route VMs on a GuixSD server.  Because I want
self-contained, portable, stateful VMs that can also run elsewhere, I
use 'guix system vm-image'. I keep track of the VM config by caching the
config file and 'guix --version' w/the image, which must be copied out
of the store in order to run (and is therefore not affected by 'guix
gc'). I keep track of what's running and avoid colisions by forcing a
1-to-1 mapping between the image file name, VM name, TUN/TAP device
name, and MAC address.

HTH - George

Re: Seeking best-practice for managing guix-defined VMs

[Ludovic Courtès]

Hello,

Hartmut Goebel <h.goebel@crazy-compilers.com> 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’.