4 ms·

Good call out. I glossed over a lot of the semantics. To be fair I could write an equally as long and drawn out article about why virtualization and a lightweig

Good call out. I glossed over a lot of the semantics. To be fair I could write an equally as long and drawn out article about why virtualization and a lightweight hypervisor is in scope for a process management mechanism.

zozbot234 4y ago
Systemd can manage virtual machines already, see systemd-machined and machinectl. It has no support for clustered/distributed state as of yet, however.
- cmeacham98 4y ago
  Those are containers, not VMs.
  - zozbot234 4y ago
    They can be either. This is expressly supported, e.g. by the libvirt tooling ecosystem.
    - cmeacham98 4y ago
      Ah, my bad, I wasn't aware machined supported VMs as well. I wonder how that works with the other systemd integrations (like viewing logs from the hypervisor OS with journalctl), I suppose it just doesn't?
      - SahAssar 4y ago
        Many systemd commands have support for remote commands by setting a --host param to the address of the machine you want to invoke the command on. It's similar to how --machine works for containers under systemd, but using ssh to communicate.
sp332 4y ago
I get that VMs have certain advantages, but I was surprised that they are the default (only?) choice for namespace management. Is it that unusual for containers to mix and match, e.g. have different filesystem namespaces, but share a network namespace?
- kris-nova 4y ago
  This is a good call out. One of the philosophies of the project I am trying to maintain is instilling my opinion into things while still having the project play nice with the rest of the ecosystem. On one hand I over-engineer a systemd hypervisor that is only meaningful to me. On the hand I create another ambiguous junk drawer that is meaningless without a team of experts to tell you how to configure everything. I think having what kubernetes calls "namespaces" as an isolation boundary on each node running as a VM is the move here. It SHOULD run like this as a default. Pods are another story. Namespaces however -- should always have a VM boundary. Getting the network device integration is going to be a big thing here. I suspect this means each namespace now has 1 or more NICs it will be able to leverage. Firecracker went with the bridge mentality which I kind of disagree with: https://github.com/firecracker-microvm/firecracker/blob/main/docs/design.md#host-integration https://github.com/firecracker-microvm/firecracker/blob/main... I want to see tools like Tailscale that leverage network devices as the "true network interface" find value in the guest namespace paradigm. Hope this helps!
  - gravypod 4y ago
    To me it sounds like it might incur a lot of overhead for minimal gains. At the end of the day you are trusting both the software and hardware implementation for isolation when using virtualization. Virtualization comes with a substantial relative performance penalty. In an ideal world, where virtualization has no performance penalty, it might make sense to wrap everything in VMs but in the real world I think having the option to switch isolation mechanisms might be the best idea. Some may need "better" (subjective) security and opt for VMs which could be the default platform. Others may be fine with something more lax like gvisor or even just having different users for each namespace.

zozbot234 4y ago

Systemd can manage virtual machines already, see systemd-machined and machinectl. It has no support for clustered/distributed state as of yet, however.

cmeacham98 4y ago
Those are containers, not VMs.
- zozbot234 4y ago
  They can be either. This is expressly supported, e.g. by the libvirt tooling ecosystem.
  - cmeacham98 4y ago
    Ah, my bad, I wasn't aware machined supported VMs as well. I wonder how that works with the other systemd integrations (like viewing logs from the hypervisor OS with journalctl), I suppose it just doesn't?
    - SahAssar 4y ago
      Many systemd commands have support for remote commands by setting a --host param to the address of the machine you want to invoke the command on. It's similar to how --machine works for containers under systemd, but using ssh to communicate.

sp332 4y ago

I get that VMs have certain advantages, but I was surprised that they are the default (only?) choice for namespace management. Is it that unusual for containers to mix and match, e.g. have different filesystem namespaces, but share a network namespace?

kris-nova 4y ago
This is a good call out. One of the philosophies of the project I am trying to maintain is instilling my opinion into things while still having the project play nice with the rest of the ecosystem. On one hand I over-engineer a systemd hypervisor that is only meaningful to me. On the hand I create another ambiguous junk drawer that is meaningless without a team of experts to tell you how to configure everything. I think having what kubernetes calls "namespaces" as an isolation boundary on each node running as a VM is the move here. It SHOULD run like this as a default. Pods are another story. Namespaces however -- should always have a VM boundary. Getting the network device integration is going to be a big thing here. I suspect this means each namespace now has 1 or more NICs it will be able to leverage. Firecracker went with the bridge mentality which I kind of disagree with: https://github.com/firecracker-microvm/firecracker/blob/main/docs/design.md#host-integration https://github.com/firecracker-microvm/firecracker/blob/main... I want to see tools like Tailscale that leverage network devices as the "true network interface" find value in the guest namespace paradigm. Hope this helps!
- gravypod 4y ago
  To me it sounds like it might incur a lot of overhead for minimal gains. At the end of the day you are trusting both the software and hardware implementation for isolation when using virtualization. Virtualization comes with a substantial relative performance penalty. In an ideal world, where virtualization has no performance penalty, it might make sense to wrap everything in VMs but in the real world I think having the option to switch isolation mechanisms might be the best idea. Some may need "better" (subjective) security and opt for VMs which could be the default platform. Others may be fine with something more lax like gvisor or even just having different users for each namespace.