3 ms·

Hello, an exe.dev person here. They are VMs, on a crosvm-derived VMM. So I consider them "actually VMs", though we do not currently support custom kernels. You

by crawshaw 10mo ago

Hello, an exe.dev person here. They are VMs, on a crosvm-derived VMM. So I consider them "actually VMs", though we do not currently support custom kernels. You can do VM things in there, like create TUN devices, etc.

ilaksh 10mo ago
Thanks. So KVM I assume. Congratulations on your launch. Any plans for public IPs?
- crawshaw 10mo ago
  Thank you! Yes, KVM. And public IPs are very useful and we want to do them. We will have to charge and/or limit them, unlike VMs, unfortunately, because IPv4 is scarce. (I am busy trying to buy some right now.) You can follow along here: https://github.com/boldsoftware/exe.dev/issues/6 https://github.com/boldsoftware/exe.dev/issues/6
jauntywundrkind 10mo ago
Not super important to me (and you state explicitly it may change) but your docs are a little out of date here, I think. crosvm versus Cloud Hypervisor / Kata Containers, is, I think, different? exe.dev ▶ doc how-exedev-works How exe.dev works (how-exedev-works) - press q to exit You're an engineer. We're engineers. Let's talk about what's going on under the hood. An "exe.dev" VM runs on a bare metal machine that exe.dev rents. We happen to use Kata Containers and Cloud Hypervisor, but that's a bit of an implementation detail (and may change!). With most providers, your VM starts with a "base image" and is given a block device. Exe.dev instead starts with a container image (by default, "exeuntu"), and hooks up an overlay filesystem to the VM. This makes creating a new VM take about two seconds. In exchange, we lose some flexibility: you don't get to choose which filesystem you're using, nor which kernel you're using. On the networking side, we don't give your VM its own public IP. Instead, we terminate HTTPS/TLS requests, and proxy them securely to your VM's web servers. For SSH, we handle ssh vmname.exe.xyz.
- crawshaw 10mo ago
  Yes our docs are out of date we are not using Kata, thanks.

ilaksh 10mo ago

Thanks. So KVM I assume. Congratulations on your launch. Any plans for public IPs?

crawshaw 10mo ago
Thank you! Yes, KVM. And public IPs are very useful and we want to do them. We will have to charge and/or limit them, unlike VMs, unfortunately, because IPv4 is scarce. (I am busy trying to buy some right now.) You can follow along here: https://github.com/boldsoftware/exe.dev/issues/6 https://github.com/boldsoftware/exe.dev/issues/6

jauntywundrkind 10mo ago

Not super important to me (and you state explicitly it may change) but your docs are a little out of date here, I think. crosvm versus Cloud Hypervisor / Kata Containers, is, I think, different? exe.dev ▶ doc how-exedev-works How exe.dev works (how-exedev-works) - press q to exit You're an engineer. We're engineers. Let's talk about what's going on under the hood. An "exe.dev" VM runs on a bare metal machine that exe.dev rents. We happen to use Kata Containers and Cloud Hypervisor, but that's a bit of an implementation detail (and may change!). With most providers, your VM starts with a "base image" and is given a block device. Exe.dev instead starts with a container image (by default, "exeuntu"), and hooks up an overlay filesystem to the VM. This makes creating a new VM take about two seconds. In exchange, we lose some flexibility: you don't get to choose which filesystem you're using, nor which kernel you're using. On the networking side, we don't give your VM its own public IP. Instead, we terminate HTTPS/TLS requests, and proxy them securely to your VM's web servers. For SSH, we handle ssh vmname.exe.xyz.

crawshaw 10mo ago
Yes our docs are out of date we are not using Kata, thanks.