unofficial mirror of help-guix@gnu.org 
 help / color / mirror / Atom feed
* Correct way to protect `guix system vm` invocations from garbage collection?
@ 2024-01-05 23:31 Ben Weinstein-Raun
  2024-01-06  7:33 ` Julien Lepiller
  0 siblings, 1 reply; 3+ messages in thread
From: Ben Weinstein-Raun @ 2024-01-05 23:31 UTC (permalink / raw)
  To: help-guix

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

Hello!


I'm working on setting up permanent virtual machines to run as services.
In order for this to work, I think I need to be sure that the various
inputs to the vm runner script are kept alive. This includes the kernel,
the initrd, and the qemu binary.


What's the easiest way to permanently mark an arbitrary store file (in
this case, the `...-run-vm.sh` script) as "alive"? e.g. is there a way
to add it to my user's profile, or some other gc-root? Or add it to a
new profile altogether?

Thanks!


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 249 bytes --]

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Correct way to protect `guix system vm` invocations from garbage collection?
  2024-01-05 23:31 Correct way to protect `guix system vm` invocations from garbage collection? Ben Weinstein-Raun
@ 2024-01-06  7:33 ` Julien Lepiller
  2024-01-06 17:09   ` Ben Weinstein-Raun
  0 siblings, 1 reply; 3+ messages in thread
From: Julien Lepiller @ 2024-01-06  7:33 UTC (permalink / raw)
  To: help-guix, Ben Weinstein-Raun

Hi Ben,

If by "as a service", you mean started by the Shepherd, you should be good: the vm path will become alive as it's part of the system.

Another solution would be to make it a gc root, which you can do by symlinking it in /var/guix/gc-roots

Le 6 janvier 2024 00:31:05 GMT+01:00, Ben Weinstein-Raun <root@benwr.net> a écrit :
>Hello!
>
>
>I'm working on setting up permanent virtual machines to run as services.
>In order for this to work, I think I need to be sure that the various
>inputs to the vm runner script are kept alive. This includes the kernel,
>the initrd, and the qemu binary.
>
>
>What's the easiest way to permanently mark an arbitrary store file (in
>this case, the `...-run-vm.sh` script) as "alive"? e.g. is there a way
>to add it to my user's profile, or some other gc-root? Or add it to a
>new profile altogether?
>
>Thanks!
>


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Correct way to protect `guix system vm` invocations from garbage collection?
  2024-01-06  7:33 ` Julien Lepiller
@ 2024-01-06 17:09   ` Ben Weinstein-Raun
  0 siblings, 0 replies; 3+ messages in thread
From: Ben Weinstein-Raun @ 2024-01-06 17:09 UTC (permalink / raw)
  To: Julien Lepiller, help-guix

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

On 01/06/24 02:33, Julien Lepiller wrote:

> If by "as a service", you mean started by the Shepherd, you should be good: the vm path will become alive as it's part of the system.

Ah, that makes sense! I assume this is only true if it's properly in a
profile (either guix home profile or the system profile) as opposed to
being added as a user-level shepherd service not inside my home
directory. I was planning to do the latter, since I'm not sure how to
properly describe the vm in a manifest (though I imagine I could examine
the source code for `guix system vm` to find out).

> Another solution would be to make it a gc root, which you can do by symlinking it in /var/guix/gc-roots
Perfect, that seems to work great! Thanks a ton!

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 249 bytes --]

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2024-01-06 17:10 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-01-05 23:31 Correct way to protect `guix system vm` invocations from garbage collection? Ben Weinstein-Raun
2024-01-06  7:33 ` Julien Lepiller
2024-01-06 17:09   ` Ben Weinstein-Raun

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).