Ludovic Courtès writes: Hello, > That was fast! :-) Yeah...we need this, right ;) > "Jan (janneke) Nieuwenhuizen" skribis: > >> and doing something like >> >> ./pre-inst-env guix system vm gnu/system/examples/bare-bones.tmpl --no-offload >> /gnu/store/96wh3jwsla4p6d4s547mmqxsi4qbbc0r-run-vm.sh -m 2G \ >> --device rtl8139,netdev=net0 \ >> --netdev user,id=net0,hostfwd=tcp:127.0.0.1:10022-:2222,hostfwd=tcp:127.0.0.1:5900-:5900 >> >> nicely starts a bare-bones VM with the the hurd-in-vm service inside, but I >> cannot seem to connect to the Hurd VM it in any way. Appending >> ",hostfwd=tcp:127.0.0.1:20022-:20022" (to directly ssh into the Hurd) even >> blocks me from ssh'ing into the GNU/linux host VM. > > Weird. > >> hurd-in-vm works beautifully when added to my system configuration and >> reconfiguring. >> >> * gnu/services/virtualization.scm (disk-image, hurd-in-vm-shepherd-service, >> hurd-vm-disk-image): New procedures. >> (%hurd-in-vm-operating-system, hurd-in-vm-service-type): New variable. >> (): New record type. >> * doc/guix.texi (Virtualization Services): Document it. > > […] > >> +@subsubheading The Hurd in a Virtual Machine >> + >> +@cindex @code{hurd} >> +@cindex the Hurd >> + >> +Service @code{hurd-in-vm} provides support for running a Virtual Machine >> +with the GNU@tie{}Hurd. > > “… support for running GNU/Hurd in a virtual machine (VM). The virtual > machine is a Shepherd service that can be controlled with commands such > as: > > @example > herd stop hurd-vm > @end example > > The given GNU/Hurd operating system configuration is cross-compiled.” Nice, thanks! > Nitpick: I’d call it “hurd-vm”, because it runs a Hurd VM. :-) Done! > It’s a volatile VM, due to the use of ‘-snapshot’, right? By default: Yes. That seemed more ready-to-use. A stateful VM image would need to an out-of-store, writable copy. You can actually do that and modify the hurd-vm-configuration. > (The Hurd actually has “sub-Hurds”¹ and “neighborhurds”². I wonder if > it’s our duty to coin another term… a guesthurd? a visithurd?) > > ¹ https://www.gnu.org/software/hurd/hurd/subhurd.html > ² https://www.gnu.org/software/hurd/hurd/neighborhurd.html Oh, that's cool! Associating along from the neighborhurd pun, what about a "childhurd" (as a pun on childhood -- only needed while the Hurd is growing up)? "herd start childhurd" -- hmm? In the updated patch, I still have hurd-vm. If we do our duty and coin "childhurd", should I just s/hurd-vm/childhurd/g ? >> +(define* (disk-image os #:key (image-size 'guess) target) >> + "Return a disk-image for OS with size IMAGE-SIZE, built for TARGET." >> + (with-store store > ^ > In general, procedures should talk to the user-provided store and never > open a new connection. They should also never call ‘build-derivations’ > explicitly, the only exception so far being the graft implementation. > > So you can drop ‘with-store’ here, and then: > >> + (run-with-store store >> + (let ((file-system-type "ext2")) >> + (mlet* %store-monad >> + ((base-image (find-image file-system-type)) >> + (sys (lower-object >> + (system-image >> + (image >> + (inherit base-image) >> + (size image-size) >> + (operating-system os))))) >> + (drvs (mapm/accumulate-builds lower-object (list sys))) >> + (% (built-derivations drvs))) >> + (let ((output (derivation->output-path sys))) >> + (return output)))) > > Mathieu, can we make ‘find-image’ non-monadic? It really shouldn’t be > because it doesn’t interact with the store. It can take an optional > ‘system’ parameter if we want. It seems that "just works". I've made that change in a separate patch (attached). > So, assuming ‘find-image’ is non-monadic, the code above becomes > something like: > > (system-image > (image (inherit base-image) > (size image-size) > (operating-system > (with-parameters ((%current-target-system "i586-pc-gnu")) > os)))) Hmm...I don't think that I understand. This --8<---------------cut here---------------start------------->8--- (define* (disk-image os #:key (image-size 'guess) target) "Return a disk-image for OS with size IMAGE-SIZE, built for TARGET." (let ((base-image (find-image "ext2"))) (system-image (image (inherit base-image) (size image-size) (operating-system (with-parameters ((%current-target-system target)) os)))))) --8<---------------cut here---------------end--------------->8--- gives --8<---------------cut here---------------start------------->8--- $ ~/src/guix/master/pre-inst-env guix system build dundal.scm %default-substitute-urls:("https://ci.guix.gnu.org") Backtrace: In ice-9/boot-9.scm: 1736:10 4 (with-exception-handler _ _ #:unwind? _ #:unwind-for-type _) In unknown file: 3 (apply-smob/0 #) In ice-9/boot-9.scm: 718:2 2 (call-with-prompt _ _ #) In ice-9/eval.scm: 619:8 1 (_ #(#(#))) In guix/ui.scm: 1945:12 0 (run-guix-command _ . _) guix/ui.scm:1945:12: In procedure run-guix-command: In procedure operating-system-file-systems: Wrong type argument: #< bindings: ((#< 7f4ce7c23740 proc: #> #)) thunk: #> --8<---------------cut here---------------end--------------->8--- ...I could do with some help here. >> +(define %hurd-in-vm-operating-system [..] >> + (operating-system >> + (service openssh-service-type >> + (openssh-configuration >> + (openssh openssh-sans-x) [..] >> + %base-services/hurd)))) > > I understand the need to factorize useful configs, but IMO it doesn’t > belong here. So I’d just leave it out. There’s already > ‘%hurd-default-operating-system’ that does the heavy lifting anyway. Sure, removed! Users will most probably want to add an openssh server using openssh-sans-x; but I guess that's something for a blog post or cookbook then. >> +(define hurd-in-vm-service-type >> + (service-type >> + (name 'hurd-in-vm) >> + (extensions (list (service-extension shepherd-root-service-type >> + hurd-in-vm-shepherd-service))) >> + (default-value (hurd-in-vm-configuration)) >> + (description >> + "Provide a Virtual Machine running the GNU Hurd."))) > > Being pedantic: s|the GNU Hurd|GNU/Hurd|. :-) > > Otherwise looks great to me, thank you! Great; thanks...find two new patches attached. Janneke