Add virtual/cloud architecture

[Rebek Kahn]

Hi,

First of all, I agree with your idea of minimize the ISO and not add something not necessary. So, please continue focusing on your real objectives.

However, I feel some people (like me) wants to run lightwhale inside a VM. I’m a big fan of Hypervisors. Therefore, I never use a baremetal computer without a hypervisor on it. And this is true when I need to run only one virtual machine on it. This provides a more convenient remote control and management. This is similar to people who want to run everything in a container. That’s my preference.

So, after reading you opinion in the Issue of “Add QEMU-GUEST-AGENT” I understand that you’re open to proposals that have sense and doesn’t break the principles of the project. Therefore, I have this suggestion:

• Create a list of different ISO architurectures, including x86_64, ARM64 and Virtual.

I know that you want to create a version for Rasberry Pi (nice!). And then why not support a Virtual version? On this platform you can add the qemu-guest-agent, open-vm-tools, virt-drivers, vmware drivers, etc. And then you get two objectives: the physical x86_64 will not be poluted with unnecessary stuff; and the users that want to run it inside one VM will obtain all necessary. Please take note that the Guest Shutdown is a must-have to use it for “production” (in a homelab). And qemu is not the only hypervisor.

I hope you want to consider this.
Thank you.

‌

‌

[Rebek Kahn]

Hi,

Regarding the support of the LigthWhale as a VM, I have an additional suggestion:

• You could add support for multiple architectures (packaged in different ISOs).
• In addition you can provide some container for “guest” tools.

The idea comes from here: https://github.com/nccurry/open-vm-tools-container-image

For example, to support a third-party hypervisor like vmware, you only need to add the corresponding kernel drivers (i.e. VMXNET3, VMWARE_PVSCSI and VMWARE_VMCI). This only increases the kernel a bit (and you at time are including other virt-drivers for qemu). And then, you only need to host/provide some container with the guest tools to run them inside the VM using the docker runtime.

You agree with that idea?

‌

[Rebek Kahn]

Hi,

My last proposal is similar to the solution presented in: https://github.com/projectatomic/atomic-system-containers

You can consider these (inspired) readonly system containers as a method to resolve the problem. Therefore the users could “attach” them to the server and they will provide the necessary stuff.

Anyway, this opens a new request: Why not include a secondary persistent storage ? My idea is this: boot the VM with the ISO as readonly and shared by other instances. Configure one big virtual disk as persistent datastore (readwrite). Then a secondary persistent (readonly-and-shared between different VMs) to store the “system containers”. And finally a third persistent disk for SWAP (not included in backups and disposable).

Please, comment your point of view.

[Stephan Henningsen]

Hi,

Thanks for your time to describe your ideas. I’m sorry, but I have to kindly reject this. What you’re suggesting will add a lot of extra work; maintaining multiple ISO is not an easy feat. Also, it would make Lightwhale a much more complex, which will defeat the purpose of this project.

However, I acknowledge the desire to run Lightwhale in a VM. And in response to that I’ve added support for various VMs into Lightwhale. The qemu-guest-agent is still missing, though; I’m still (occasionally) working on a nice solution of this, and there’s slow progress.

[Stephan Henningsen]

VM partially fixed; multiple ISOs is too complex a task.