> If you don't specify an execution environment for your service, Cloud Run can select either the first generation or the second generation environment.
It just sounds like a long migration process (and office politics), to me.
Alright does this also mean we are detaching some of the google specific stuff and or are more accepting of open standards related changes?
Though tbh I don't have much to complain about GVisor project, one of the nicer projects I have worked more with other things though but it's not that bad.
Does anyone know if it has capabilities that would be useful in running retro-games? I'm imagining a guest KMS-> host SDL conversion, or indeed something like virtio-gpu?
Last I looked (years) those were very much 'not intended use'.
gVisor does support NVIDIA GPUs and some Vulkan ioctls are supported. If you want to run games in it and find incompatibilities, patches welcome :) Agents are great at completing gVisor's nvproxy ioctls nowadays.
I've personally run Unreal Tournament 2004 at 40fps on my laptop, with pure software-rendered OpenGL a few years ago (GPU support wasn't there at the time).
gVisor is still pretty useful for untrusted workloads when you don't have KVM, though it gets harder to integrate into workflows where people are running macOS/windows locally
the article is quite pessimistic but looking at the latest cves found, most of them are mitigated:
https://gvisor.dev/security-track-record/ (and those are big ones currently, full container escapes..)
I like gvisor but I fear this is too little, too late. Microvms are crushing it right now. I believe even Modal, which is one of the few non-Google users deploying gvisor commercially, and heavily called out in TFA, are moving off gvisor in favor of microvms. Unreal!
Frankly I would never want to operate gvisor with customer defined workloads.
For one, performance isn't native, which makes it hard to determine workload characteristics. Second, it has a pretty long list of limitations that make it difficult to deploy transparently: cgroups aren't fully supported, no io_uring, etc.
They claim they test a wide array of workloads but there are still compatibility issues that take years to iron out. I once had a workload that was probably buggy, and crashed only on arm64 under gvisor, but as I lacked source access there was no viable path forward.
I hope I am wrong, I'd love to see gvisor really take off. I think finishing the macOS port would be wild: run Linux binaries on macOS without a VM! But I'm not confident.
Background: Google Cloud Run moved away from gVisor in 2023
https://cloud.google.com/blog/products/serverless/cloud-run-...
That's not true. The majority of Cloud Run jobs still run on gVisor. The "gen 2" runtime is technically not even on by default.
https://docs.cloud.google.com/run/docs/configuring/execution...
Meanwhile,
> If you don't specify an execution environment for your service, Cloud Run can select either the first generation or the second generation environment.
It just sounds like a long migration process (and office politics), to me.
Try running `dmesg` in your Cloud Run instance and see for yourself if that's actually the case :)
Alright does this also mean we are detaching some of the google specific stuff and or are more accepting of open standards related changes?
Though tbh I don't have much to complain about GVisor project, one of the nicer projects I have worked more with other things though but it's not that bad.
Does anyone know if it has capabilities that would be useful in running retro-games? I'm imagining a guest KMS-> host SDL conversion, or indeed something like virtio-gpu?
Last I looked (years) those were very much 'not intended use'.
gVisor does support NVIDIA GPUs and some Vulkan ioctls are supported. If you want to run games in it and find incompatibilities, patches welcome :) Agents are great at completing gVisor's nvproxy ioctls nowadays.
I've personally run Unreal Tournament 2004 at 40fps on my laptop, with pure software-rendered OpenGL a few years ago (GPU support wasn't there at the time).
gVisor is still pretty useful for untrusted workloads when you don't have KVM, though it gets harder to integrate into workflows where people are running macOS/windows locally
the article is quite pessimistic but looking at the latest cves found, most of them are mitigated: https://gvisor.dev/security-track-record/ (and those are big ones currently, full container escapes..)
The networking stack is actually used by many open source project such as tailscale
Hope this shift will make the project get sustainable and evolve fast
They don't even sufficiently describe what it actually does and why it would be a better choice than a micro VM or whatever you call it these days
Good night, GVisor.
I like gvisor but I fear this is too little, too late. Microvms are crushing it right now. I believe even Modal, which is one of the few non-Google users deploying gvisor commercially, and heavily called out in TFA, are moving off gvisor in favor of microvms. Unreal!
Frankly I would never want to operate gvisor with customer defined workloads.
For one, performance isn't native, which makes it hard to determine workload characteristics. Second, it has a pretty long list of limitations that make it difficult to deploy transparently: cgroups aren't fully supported, no io_uring, etc.
They claim they test a wide array of workloads but there are still compatibility issues that take years to iron out. I once had a workload that was probably buggy, and crashed only on arm64 under gvisor, but as I lacked source access there was no viable path forward.
I hope I am wrong, I'd love to see gvisor really take off. I think finishing the macOS port would be wild: run Linux binaries on macOS without a VM! But I'm not confident.