GVisor is being donated to CNCF

(gvisor.dev)

22 points | by birdculture a day ago ago

8 comments

  • minraws a day ago ago

    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.

  • anotherhue 21 hours ago ago

    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'.

  • trashcan2137 19 hours ago ago

    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

  • iercan 21 hours ago ago

    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..)

  • mintflow a day ago ago

    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

  • bananaquant 16 hours ago ago

    Good night, GVisor.

  • aidiveyt 2 hours ago ago

    [flagged]

  • xyzzy_plugh a day ago ago

    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.