Examples of mounting volumes

[networkop]

I was trying to find a good example of e2e UX for mounting volumes. I've only been able to find this https://github.com/weaveworks/ignite/blob/main/e2e/run_volume_test.go#L17
Is there a better, user-friendly example?

[dit7ya]

Have you found something? I am trying to figure this out and its so confusing. Following the link above what I got was one directional mount only - changes in the VM reflected in host but not the other way round.

[networkop]

nope and it looks like the host mounts are not supported at all. I think I've read somewhere that this is by (FC's) design. But it'd be nice to at least document what's possible and what are the limitations.

[dit7ya]

Apparently this is a feature?
I am not sure if #275 PR does what we are talking about.

[networkop]

I was referring to this #76 (comment)
The way I read it is that 2-way mounts are not supported. is that how you understand it as well?

[darkowlzz]

Hi, currently, we only support exposing block volumes inside a VM as mentioned in #76 and shown in the e2e volume test. Mounting the VM block file on host and writing to it does not work, maybe because it's managed by the device mapper snapshotter when the VM is active.

@networkop and @dit7ya can you explain more about your requirements, what are you looking for or trying to do? Maybe we can discuss and figure out a workaround for your needs.

The volume test example is straight forward, create a block file and use it with a VM. We can add a docs page with more examples and details about it if that'll be helpful.

[dit7ya]

@darkowlzz My requirement is this - The VM can both read and write to a persistent directory in the host - which the host can also read and write to at the same time - keeping them both in sync.

To explain my use case better - I am creating an API for executing arbitrary code. I want the code to be run in a secure environment but want the API server out of the VM (to keep it stable in case the VM crashes). So my idea was to store the code in a directory in the host and let the VM access that directory only.

[darkowlzz]

@dit7ya interesting use case. But unfortunately, we don't support mounting directories yet.
A workaround for your case could be to use the ignite cp command to copy the files from your host to the VM and get the result from VM to host using the same. We have some examples of the cp command to do the same in the e2e test https://github.com/weaveworks/ignite/blob/main/e2e/cp_test.go . You may combine this along with ignite run --copy-files flag, based on your requirement, if the files should be in the VM when it starts. Hope this way, your host API server will be able to run arbitrary code inside the VM and be able to get the result from the VM if needed.

[stealthybox]

@dit7ya while there are technical limitations for this right now.

Here are some options you could explore:

You could create an ext4 loopback device with losetup that contains a copy of the source code you're intending to run. This device would mount into the VM and you could read/write it internally.
You could also inspect the loopback file system from the outside while or after the VM is done running.

If you start the VM with SSH enabled, ignite cp could fit your use-case.
Copy the code into the VM before you execute it -- copy any needed output files back out afterwards if that's a requirement.

Also along the lines of VM's with SSH, you could install sshocker on the host and sshfs in the VM and get a full network mount.
Here's a quick example:

sudo ignite run --name code-vm --ssh weaveworks/ignite-ubuntu
sudo ignite exec code-vm -- "apt update && apt install -y sshfs"

cat <<EOF > code-vm.sshconfig
Host code-vm
  Hostname $(ignite inspect vm code-vm -t "{{index .Status.Network.IPAddresses 0}}")
  IdentityFile /var/lib/firecracker/vm/$(ignite inspect vm code-vm -t "{{.ObjectMeta.UID}}")/id_$(ignite inspect vm code-vm -t "{{.ObjectMeta.UID}}")
  StrictHostKeyChecking no
EOF

# execute your code
sudo sshocker -v ./:/mnt/ssh/code -F code-vm.sshconfig code-vm  ls /mnt/ssh/code # your command here

Using NFS from the host to the guest could also be faster, but the sshocker solution feels quite good.

[solarkraft]

we don't support mounting directories yet

This might be a reason I'll have to go with Kata containers even though I'd really like to use Ignite for its simplicity.

It could've been a workaround for #874.

Since Firecracker doesn't seem to have this feature and doesn't plan to have it (firecracker-microvm/firecracker#889) I suppose it's not coming to Ignite either (which is super unfortunate!).