Seeking working, complete example for a vm

Seeking working, complete example for a vm

[Hartmut Goebel]

Hi,

for a demonstration I need to set up a container running nginx and
postres and maybe ssh. nginx and ssh should be accessible from outside
the vm, at least from the host. After some struggle with building the vm
[1] I'm now able to boot it. I already copy the image our of the store
(as advised in the manual). But I still experience some problems:

1) lsh wants keystrokes a random-seed on each boot. This looks like
file-system will not be preserved over reboots. How can I solve this?

2) Using "guix system reconfigure" *within* the vm would be great. But
where do I find the system declaration within the vm? Or is it
preferable to share my working directory?

3) How can I *easiest* setup networking, either bridged or "NAT" (how
virtualbox names it). Since this

4) Can I specify this in the system declaration? Or is there some other
way to declare the vm, including all the parameters to be passed to
qemu? If not, this is not much of a problem, as another bash-script
would do the job.

9) Minor glitch: How can I turn of the colour in ls using the system
declaration?

Thanks in advance for all tips.

[1] On the host, /dev/kvm needs to have group kvm and g+rx and
guixbuild..-users need to be members of this group, This is written in
the manual, but not emphasised.

-- 
Regards
Hartmut Goebel

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

Re: Seeking working, complete example for a vm

[Leo Famulari]

On Fri, Oct 28, 2016 at 01:01:22PM +0200, Hartmut Goebel wrote:
> Hi,
> 
> for a demonstration I need to set up a container running nginx and
> postres and maybe ssh. nginx and ssh should be accessible from outside
> the vm, at least from the host. After some struggle with building the vm
> [1] I'm now able to boot it. I already copy the image our of the store
> (as advised in the manual). But I still experience some problems:

Can you clarify if you are trying to use a container or a VM?

Re: Seeking working, complete example for a vm

[Hartmut Goebel]

Am 28.10.2016 um 18:27 schrieb Leo Famulari:
> Can you clarify if you are trying to use a container or a VM?
Sorry for the confusion: I'm trying to set up a vm.

(I tried container first, but davexunit informed me that networking is
not yet implemented there, so I switched to vm.)

-- 
Regards
Hartmut Goebel

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

Re: Seeking working, complete example for a vm

[Leo Famulari]

On Fri, Oct 28, 2016 at 06:52:25PM +0200, Hartmut Goebel wrote:
> Am 28.10.2016 um 18:27 schrieb Leo Famulari:
> > Can you clarify if you are trying to use a container or a VM?
> Sorry for the confusion: I'm trying to set up a vm.
> 
> (I tried container first, but davexunit informed me that networking is
> not yet implemented there, so I switched to vm.)

`guix system vm` creates an immutable system that shares the host's
store. The annoying LSH host key issue will be the first problem if you
want to write to the filesystem. Since it lives in the store, you can't
mutate it. I think that parts of the filesystem are mutable RAM-backed
partitions.

`guix system vm-image` creates a system with its own store that is meant
to be copied out of /gnu/store and mutated. It requires some manual
steps, as you pointed out.

I don't know the implementation details of these tools very well, but
that's my understanding based on using the tools.

Re: Seeking working, complete example for a vm

[Ludovic Courtès]

Hello!

Leo Famulari <leo@famulari.name> skribis:

> On Fri, Oct 28, 2016 at 06:52:25PM +0200, Hartmut Goebel wrote:
>> Am 28.10.2016 um 18:27 schrieb Leo Famulari:
>> > Can you clarify if you are trying to use a container or a VM?
>> Sorry for the confusion: I'm trying to set up a vm.
>> 
>> (I tried container first, but davexunit informed me that networking is
>> not yet implemented there, so I switched to vm.)
>
> `guix system vm` creates an immutable system that shares the host's
> store. The annoying LSH host key issue will be the first problem if you
> want to write to the filesystem. Since it lives in the store, you can't
> mutate it. I think that parts of the filesystem are mutable RAM-backed
> partitions.

The host key of lshd lives in /etc, not in the store (it would be a
security problem because the store is world-readable).

The “annoying” thing when using the lsh service is that it wants you to
type so that it can seed its PRNG.  Now, you can use OpenSSH or Dropbear
to sidestep that.

The image returned by ‘guix system vm’ has a writable RAM-backed root
file system.  It has a read-only store though, meaning you cannot
perform Guix operations in it.

Ludo’.

Re: Seeking working, complete example for a vm

[Ludovic Courtès]

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

> 1) lsh wants keystrokes a random-seed on each boot. This looks like
> file-system will not be preserved over reboots. How can I solve this?

Use OpenSSH.  ;-)  The root file system is indeed volatile.

> 2) Using "guix system reconfigure" *within* the vm would be great. But
> where do I find the system declaration within the vm? Or is it
> preferable to share my working directory?

The OS declaration is not in the VM, unless you share it with --expose
or --share.

> 3) How can I *easiest* setup networking, either bridged or "NAT" (how
> virtualbox names it). Since this

Networking works out of the box in the VM.

If you want the VM to be reachable from the outside, the easiest
solution is port forwarding:

  https://lists.gnu.org/archive/html/guix-devel/2016-09/msg01857.html

> 4) Can I specify this in the system declaration? Or is there some other
> way to declare the vm, including all the parameters to be passed to
> qemu? If not, this is not much of a problem, as another bash-script
> would do the job.

The OS declarations only describes the OS in the VM, not the QEMU
parameters.

> 9) Minor glitch: How can I turn of the colour in ls using the system
> declaration?

Just “unalias ls” (the alias comes from the default ~/.bashrc).

> [1] On the host, /dev/kvm needs to have group kvm and g+rx and
> guixbuild..-users need to be members of this group, This is written in
> the manual, but not emphasised.

Maybe we could move the note in
<https://www.gnu.org/software/guix/manual/html_node/Invoking-guix-system.html>
higher, in the description of the ‘vm’ sub-command?

HTH!

Ludo’.

Re: Seeking working, complete example for a vm

[myglc2]

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

On 10/28/2016 at 13:01 Hartmut Goebel writes:

> Hi,
>
> for a demonstration I need to set up a container running nginx and
> postres and maybe ssh. nginx and ssh should be accessible from outside
> the vm, at least from the host. 

In an effort to reply to your request for a "working, complete example,"
I attach the hackage that I use to manage the care and feeding of
LAN-visible GuixSD VM images running on a headless GuixSD server.

For details please see the comments in 'aba'

HTH - George

[-- Attachment #2: aba --]
[-- Type: application/octet-stream, Size: 6291 bytes --]

#!/run/current-system/profile/bin/bash

# set -ex

# Run GuixSD VM image using QEMU/KVM and, optionally, TAP routed
# networking.

# naming conventions:
#   script name must be:    3 chars selected from [0-9A-G]
#   VM name (NAME) will be: <scriptname><0|vm#>
#   MAC address will be:    AA:00:00:00:NA:ME
#   IP address will be:     192.168.1.131
#   gateway will be:        192.168.1.1
#   DNS will be             192.168.1.1

# Addresses are set by this script or by running sed on the VM config
# file which is, by default, named: <scriptname>.scm

# example:
# script name: aba
# make vm:     ./aba mk 3
# run  vm:     sudo ./aba run 3
# VM name:     aba3
# MAC:         AA:00:00:00:AB:A3

# Cheat Sheet:
# ./aba mk 1                 # make VM aba1
# sudo ./aba route 1         # enable LAN access
# sudo ./aba x 1             # start VM w/ X Window console
#      - play the pianno     # provide randomness for key gen
#      - login root          # log in as root
#        - passwd g1         # set user g1 password
#        - shutdown          # shut down the VM
# sudo ./aba up 1            # run VM in background
# ssh g1@192.168.1.31        # log in to VM aba1 from LAN client

# usage details:

# $ ./<scriptname> mk  [vm#]
#                make VM

# Every VM must be initilized by either 'run' or 'x' in order to "play
# the piano" on the consoleto create the random seed and to set
# passwords for root and users:

# $ sudo ./<scriptname> run [vm#]
#                run and open console in terminal so we can
#                "play the piano" to generate random seed.
#                NOTE: when you kill the console the VM dies

# $ sudo ./<scriptname> x   [vm#]
#                run in bg & open console in X window
#                NOTE: when you kill X console the VM will dies
 
# After being initilized, a VM may be taken up or down

# $ sudo ./<scriptname> up  [vm#]
#                bring VM up in bg w/ no console

# To control LAN access to the VM, 'route' or 'unroute' it.

# $ sudo ./<scriptname> route [vm#]
#                set up LAN routing

# $ sudo ./<scriptname> unroute [vm#]
#                take down LAN routing

# to display the currently running VMs and enabled LAN routes

# $ ./<scriptname> show
#                show the running VMs and routed TAP interfaces

CMD=`basename "$0"`
VMNUM=${2:-""}
NAME=$CMD$VMNUM
VMDIR=$PWD/vm/$NAME
# TODO support NAME length > 4 char
MACIN=AA000000$NAME
MAC=$(echo $MACIN | sed -e 's/[0-9A-Fa-f]\{2\}/&:/g' -e 's/:$//')

case $1 in
    mk)
	mkdir -p vm
	# fail so we don't clobber an existing VM
	mkdir $VMDIR
	cp -f $CMD $VMDIR/$CMD
	# make an image
	# save the vm config
	sed s/v1/$NAME/ aba.scm > $VMDIR/v0.scm
	sed s/31/3$VMNUM/ $VMDIR/v0.scm > $VMDIR/v1.scm
	# save guix version 
	(stat $HOME/.config/guix/latest | grep File:) > $VMDIR/guix-version
	# save guix config
	git -C ~/.config/guix/latest branch -av | grep '* master' >> $VMDIR/guix-version
	# be sure the version of guix we have checked out is the one we are using
	make -C $HOME/.config/guix/latest -s > $VMDIR/guix-make.log
	# make vm image & copy from store
	cp -f $(guix system vm-image $VMDIR/v1.scm --image-size=4GB) $VMDIR/vm.img
	# make the image writeable
	chmod u+w $VMDIR/vm.img
	;;

    destroy)
	# destroy the vm
	rm -fr $VMDIR
	;;

    route)
	# TODO take-down and restart if already exists
	# enable LAN access via ARP proxy
	sudo sysctl -w net.ipv4.ip_forward=1            # allow IPv4 forwarding
	sudo sysctl net.ipv4.conf.enp2s0.proxy_arp=1    # publish routing info for interface
	# create the TAP device with ARP proxy
	ip tuntap add dev $NAME mode tap                # create TAP device
	ip link set $NAME up                            # turn TAP device on
	sudo route add 192.168.1.13$VMNUM dev $NAME     # add route to the TAP device
	sudo sysctl net.ipv4.conf.$NAME.proxy_arp=1     # ARP proxy
	;;

    unroute)
	# remove the TAP device with ARP proxy
	sudo sysctl net.ipv4.conf.$NAME.proxy_arp=0     # disable ARP proxy
	sudo route del 192.168.1.13$VMNUM dev $NAME     # delete route to the TAP device
	ip link set $NAME down                          # turn TAP device off
	ip tuntap del dev $NAME mode tap                # delete TAP device
	;;

    run)
	# run console in foreground in terminal
	# note: qemu-ifup and qemu-ifdn are no-ops specified to avoid default call to /dev/net/tun which fails
	echo starting VM: $NAME w/MAC: $MAC
	qemu-system-x86_64 \
	    -net tap,ifname=$NAME,vlan=0,script=/home/g1/src/vma/qemu-ifup,downscript=/home/g1/src/vma/qemu-ifdn \
	    -net nic,model=virtio,macaddr=$MAC \
	    -enable-kvm \
	    -m 4096 \
	    -curses \
	    -name $NAME \
	    $VMDIR/vm.img
	;;

    x)
	# run console in background w/console in X window
	echo starting VM: $NAME w/MAC: $MAC
	# note: '-k en-us' seems required for Mac XQuartz keymap, but option it still broken
	qemu-system-x86_64 \
	    -net tap,ifname=$NAME,vlan=0,script=/home/g1/src/vma/qemu-ifup,downscript=/home/g1/src/vma/qemu-ifdn \
	    -net nic,model=virtio,macaddr=$MAC \
	    -enable-kvm \
	    -m 4096 \
	    -k en-us \
	    -daemonize \
	    -name $NAME \
	    $VMDIR/vm.img
	;;

    up)
	# run in bg with inaccessible console
	echo starting VM: $NAME w/MAC: $MAC
	qemu-system-x86_64 \
	    -net tap,ifname=$NAME,vlan=0,script=/home/g1/src/vma/qemu-ifup,downscript=/home/g1/src/vma/qemu-ifdn \
	    -net nic,model=virtio,macaddr=$MAC \
	    -enable-kvm \
	    -m 4096 \
	    -daemonize \
	    -display none \
	    -name $NAME \
	    $VMDIR/vm.img
	;;

    show)
	# show info about VMs
	echo VMs Available: `ls vm`
	echo VMs running:
	pstree -ap | grep tap | grep -v grep
	echo VMs routed:
	ip a | grep aba
	;;

    *)
	echo ERROR: you typed: \"$CMD $*\" which has missing arguments or invalid arguments
	echo Cheat Sheet: 
	echo ./aba mk 1                 # make VM aba1
	echo sudo ./aba route 1         # enable LAN access
	echo sudo ./aba x 1             # start VM w/ X Window console
	echo      - play the pianno     # provide randomness for key gen
	echo      - login root          # log in as root
	echo        - passwd g1         # set user g1 password
	echo        - shutdown          # shut down the VM
	echo sudo ./aba up 1            # run VM in background
	echo ssh g1@192.168.1.31        # log in to VM from LAN client	
esac

[-- Attachment #3: aba.scm --]
[-- Type: application/octet-stream, Size: 1803 bytes --]

;;; v1 system config
;;; following http://paste.lisp.org/display/145436
(use-modules (gnu))
(use-service-modules networking ssh)
(use-package-modules
 base                  ; glibc-utf8-locales
 admin
 disk
 linux                 ; mdadm
 package-management    ; guix
 screen
 ghostscript           ; gs-fonts
 fonts                 ; font-dejavu font-gnu-freefont-ttf
 curl                  ;lpaste
 ssh                   ; openssh mosh
 rsync
 wget
 version-control       ; git
 aspell                ; aspell-dict-en
 emacs                 ; emacs-no-x-toolkit
 gv
 autotools             ; automake
 texinfo
 gettext
 xorg certs
 graphviz
 qemu
 )
(operating-system
  (host-name "v1")
  (timezone "America/New_York")
  (locale "en_US.utf8")
  (bootloader (grub-configuration (device "/dev/sda")))
  (file-systems (cons (file-system
			(device "g1sd")
			(title 'label)
			(mount-point "/")
			(type "ext4"))
		      %base-file-systems))
  (users (cons* (user-account
		 (name "g1")
		 (group "users")
		 (supplementary-groups '("wheel" "kvm"))
		 (home-directory "/home/g1"))
		%base-user-accounts))
  (packages
   (cons*
    glibc-utf8-locales
    parted
    qemu
    guix
    screen
    openssh nss-certs xauth mosh
    rsync wget curl ;lpaste
    git
    gs-fonts font-dejavu font-gnu-freefont-ttf
    aspell aspell-dict-en
    emacs-no-x-toolkit 
    flycheck paredit magit gv
    emacs-zenburn-theme emacs-markdown-mode emacs-web-mode 
    gnu-make
    texinfo
    automake
    graphviz
    gnu-make
    texinfo automake
    %base-packages))
  (services (cons*
	     ;; (dhcp-client-service)
	     ;; Ethernet.
	     (static-networking-service "eth0" "192.168.1.131"
					#:gateway "192.168.1.1"
					#:name-servers '("192.168.1.1"))
	     (lsh-service #:root-login? #t)
	     %base-services)))

[-- Attachment #4: qemu-ifdn --]
[-- Type: application/octet-stream, Size: 360 bytes --]

#!/run/current-system/profile/bin/bash
set -e

bridge=br0

if [ -n "$1" ];then
    # operations we could do to take a QEMU TAP interface down
    # but which seem to be unnecessary.
    # ip link set $1 down
    sleep 0.5s
    # ip link set $1 nomaster
    # ip tuntap del dev $1 mode tap
    exit 0
else
    echo "Error: no interface specified"
    exit 1
fi

[-- Attachment #5: qemu-ifup --]
[-- Type: application/octet-stream, Size: 437 bytes --]

#!/run/current-system/profile/bin/bash
set -e

bridge=br0

if [ -n "$1" ];then    
    # QEMU -net tap,ifname=$NAME,vlan=0 seems effect the operation below
    # ip tuntap add dev $1 mode tap # user `whoami`
    # but we need to enslave the interface to the desired bridge
    # ip link set $1 up
    sleep 0.5s
    # ip link set $1 master $bridge
    # bridge link
    exit 0
else
    echo "Error: no interface specified"
    exit 1
fi

Re: Seeking working, complete example for a vm

[Hartmut Goebel]

Am 29.10.2016 um 01:57 schrieb Ludovic Courtès:
> [... some tipps ...]

Thanks a lot. I was able to get a machine up and running and access it.

> Maybe we could move the note in
> <https://www.gnu.org/software/guix/manual/html_node/Invoking-guix-system.html>
> higher, in the description of the ‘vm’ sub-command?

I've put "reworking the guix system manual part" on my todo list. I'm
afraid, this will not happen soon, tough.

-- 
Regards
Hartmut Goebel

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

Re: Seeking working, complete example for a vm

[myglc2]

On 11/02/2016 at 22:15 Hartmut Goebel writes:

> Am 31.10.2016 um 19:18 schrieb myglc2:
>> In an effort to reply to your request for a "working, complete example,"
>> I attach the hackage that I use to manage the care and feeding of
>> LAN-visible GuixSD VM images running on a headless GuixSD server.
>
> Thanks for sharing this. And how to you manage the images? I mean: how
> to you toll your GuixSD server to forward packages to the images?

You are very welcome ;-)

I ssh or mosh into a VM and use 'guix pull' and/or 'guix package' and/or
'guix system reconfigure' to manage it. Alternatively, I replace it with
a whole new VM.

The type of "guest" VMs created by this script using 'guix system
vm-image' are "free-standing." They are fully independent of the "host"
machine's configuration/store and should run (not tested) on any host OS
supporting qemu/kvm (probably with mods to the qemu and TAP
parameters). So the only "synergy" between the host machine and guest
VMs is that VM creation goes more quickly if a "similar" VM has been
previously created and/or packages used by the VM have been previously
installed.

AIUI, if you instead use guest VMs created using 'guix system vm' you
gain the advantage of sharing the store and, if you like, other
files. So such VMs are smaller and are created and loaded more
quickly. AIUI, this means that, if you have already installed a package
on the host and/or another guest VM, subsequent installations on other
guest VMs and/or the host machine will "re-use" that package from the
host machine's store and thus go faster.

AFAIK, there is no way to automatically "forward packages" to either
type of Guix VM (hopefully others will correct me if this is wrong).

HTH, - George