bug#39815: Sharing the store between a host and a guest

bug#39815: Sharing the store between a host and a guest

[Damien Cassou]

Hi,

`guix system vm` generates a VM which shares /gnu/store with the
host. However, the share is done read-only.  The info pages recommends
copying the VM image and making it writable.

Is it possible/recommended to get a writable and shared /gnu/store in
the VM?

Best,

-- 
Damien Cassou

"Success is the ability to go from one failure to another without
losing enthusiasm." --Winston Churchill

bug#39815: Sharing the store between a host and a guest

[raingloom]

Would have to share the connection with the Guix daemon. The VM would 
see the changes but it could write to the store directly. But that's 
effectively what you want. When you use guix as a user, the guix 
command doesn't write to the store, it tells the daemon to do things. 
Same deal here.

On Thu, Feb 27, 2020 at 21:28, Damien Cassou <damien@cassou.me> wrote:
> Hi,
> 
> `guix system vm` generates a VM which shares /gnu/store with the
> host. However, the share is done read-only.  The info pages recommends
> copying the VM image and making it writable.
> 
> Is it possible/recommended to get a writable and shared /gnu/store in
> the VM?
> 
> Best,
> 
> --
> Damien Cassou
> 
> "Success is the ability to go from one failure to another without
> losing enthusiasm." --Winston Churchill
> 
> 
> 

bug#39815: Sharing the store between a host and a guest

[Damien Cassou]

Hi,

I kept experimenting. I can't manage to install anything in the VM:

$ guix pull
Updating channel 'guix' from Git repository at 'file:///home/cassou/...'
guix pull: error: Git error: failed to mmap. Could not write data:
Invalid argument

The folder at 'file:///home/cassou/...' contains a git clone of Guix
repository and the VM has read-write access to it.

$ mount | grep /gnu/store
/dev/vda1 on /gnu/store type ext4 (ro,relatime)

I don't understand why /gnu/store is mounted read-only. Also, I haven't
done that myself.

$ cat ./build-vm.sh
#!/bin/sh

FILE=$(guix system vm-image ./current.scm --save-provenance --image-size=6G --share=/home/cassou=/mnt/host-home)

cp -f "$FILE" ./image.qcow2

$ cat ./start-vm.sh
#!/bin/sh

qemu-system-x86_64 \
    -nic user,model=virtio-net-pci \
    -enable-kvm \
    -m 4G \
    -device virtio-blk,drive=myhd \
    -drive if=none,file=./image.qcow2,id=myhd \
    -virtfs local,path="/home/cassou",security_model=none,mount_tag="host-home" \
    -virtfs local,path="./share/home",security_model=none,mount_tag="guest-home"


As you can see, I'm not even trying to share the store. Moreover, I
think the --share option passed to `guix system vm-image` above doesn't
do anything. If it is the case, I would expect the command to complain
about the unknown parameter.

Can anyone please give me a clue as to what is happening and why? Is
there a way I can install applications in my VM?

-- 
Damien Cassou

"Success is the ability to go from one failure to another without
losing enthusiasm." --Winston Churchill

bug#39815: Sharing the store between a host and a guest

[Leo Famulari]

Hi Damien,

Currently Guix does not include tools to support your use case of
"writable and shared /gnu/store in the VM".

`guix system container` might be useful but the isolation guarantees are
weaker than with QEMU. However, QEMU is not bulletproof either.

The recommended way to get a writeable store in a VM is to use `guix
system vm-image`, copy the image out of /gnu/store, make it writeable
with `chmod`, and then run it in QEMU. This will not share the store
with the host.

As you found, what you get with `guix system vm` is read-only. Even
though you copied build-vm.sh out of /gnu/store, it is just a shell
script that refers to immutable data in the host /gnu/store.

In order to share the store with a VM, you would need to also share the
store database — at least /var/guix/db if not all of /var/guix — and
also use the host's guix-daemon.

It would be great to support your use case but I don't think anyone has
worked on it yet.

Leo

bug#39815: Sharing the store between a host and a guest

[Damien Cassou]

Hi Léo,

Leo Famulari <leo@famulari.name> writes:
> Currently Guix does not include tools to support your use case of
> "writable and shared /gnu/store in the VM" […]

Thank you very much for your extensive explanation. I understand things
better now.

-- 
Damien Cassou

"Success is the ability to go from one failure to another without
losing enthusiasm." --Winston Churchill

bug#39815: Sharing the store between a host and a guest

[Ludovic Courtès]

Hi!

Leo Famulari <leo@famulari.name> skribis:

> As you found, what you get with `guix system vm` is read-only. Even
> though you copied build-vm.sh out of /gnu/store, it is just a shell
> script that refers to immutable data in the host /gnu/store.
>
> In order to share the store with a VM, you would need to also share the
> store database — at least /var/guix/db if not all of /var/guix — and
> also use the host's guix-daemon.
>
> It would be great to support your use case but I don't think anyone has
> worked on it yet.

Unfortunately, the Unix-domain socket in /var/guix/daemon-socket cannot
be shared over 9p AFAICS (with ‘guix system vm --expose’).

However, one thing that could work is to:

  1. in the guest, set GUIX_DAEMON_SOCKET=guix://localhost:1234;

  2. set up QEMU port forwarding such that the guest’s port 1234 is
     somehow redirected to a port the host guix-daemon listens to (with
     ‘--listen’);

  3. share /var/guix with the guest.

It would be easier if Unix-domain sockets could be forwarded between the
host and the guest, but that doesn’t seem to be the case.  :-/

Ludo’.

bug#39815: Sharing the store between a host and a guest

[Damien Cassou]

Ludovic Courtès <ludo@gnu.org> writes:
> However, one thing that could work is to:
>
>   1. in the guest, set GUIX_DAEMON_SOCKET=guix://localhost:1234;
>
>   2. set up QEMU port forwarding such that the guest’s port 1234 is
>      somehow redirected to a port the host guix-daemon listens to (with
>      ‘--listen’);
>
>   3. share /var/guix with the guest.
>
> It would be easier if Unix-domain sockets could be forwarded between the
> host and the guest, but that doesn’t seem to be the case.  :-/

thank you Ludovic.

-- 
Damien Cassou

"Success is the ability to go from one failure to another without
losing enthusiasm." --Winston Churchill