DE · EN

Call us

build 6ddc7a35 | content blog-content@417154f · 338 posts | profiles 32 · corpus 315 | ● 0 skipped | built 2026-10-21 12:35 UTC format run

$ soultec get service/virtualization-container -o yaml$ soultec get service/virtualization-container -o json$ soultec get service/virtualization-container -o toml$ soultec get service/virtualization-container -o xml$ python3 virtualization-container.pyPS> ./virtualization-container.ps1$ go run virtualization-container.go$ node virtualization-container.js

apiVersion: soultec.ch/v1kind: Servicemetadata: name: virtualization-container locale: en labels: group: infrastructure capability/virtualization: 1.42 capability/containers: 2.51 vendor/vmware: 0.98 annotations: source: src/content/services/en/virtualization-container.md route: /en/services/virtualization-container/ schema: /nerd/schema/services.json markdown: /en/services/virtualization-container.mdspec: title: Virtualization group: infrastructure audience: [enterprise, provider] order: 10 tags: [virtualization, containers] vendors: [vmware] summary: >- Server and desktop virtualization, and a route to containers over a platform your team already knows. photoNeed: >- Infrastructure work in progress at a customer site or in our lab: hands on hardware, a rack door open, a screen mid-configuration stub: false draft: false sections: - heading:

Virtualization

body: | Virtualizing server and desktop infrastructure improves utilisation, raises availability and simplifies management. That has been true for twenty years and still is. - heading:

The route to containers

body: | Containers are where many estates stall, because the obvious answer is a second platform: its own operating model, its own monitoring, its own permissions. Through vSphere Kubernetes Service, formerly vSphere with Tanzu, the container platform runs on the virtualization that is already there. If your team knows vSphere, the way in is much shorter than it looks. - heading:

How responsibilities stay where they are

body: | The mechanism behind it is the vSphere namespace, and it extends something your team already knows: the resource pool. The vSphere administrator still runs vSphere and assigns the namespace the resources it should get. From there the other side works through the Kubernetes API and `kubectl`, without ever touching the vSphere platform. Development and operations share a boundary rather than a tool, and that is the difference from standing up a second platform beside the first. Workloads then run either as pods directly on the platform or in their own Kubernetes clusters operated as virtual machines. - heading:

What we do for it

body: | Concept and implementation of the server infrastructure, then lifecycle, patching and updates and the tuning for operation. We build the container infrastructure from small to large. Standardisation is on VMware Cloud Foundation, because an estate built to the reference architecture brings fewer surprises at every update. - heading:

How we start

body: | Usually with a proof of concept. Container infrastructure is an area where the requirements only surface once something runs: storage classes, networking and permissions get decided by the first real use case, and then for every one after it.status: corpus: 315 solutions: - {ref: solutions/vmware/vmware-cloud-foundation/vks, score: 1.00} - {ref: solutions/vmware/vmware-cloud-foundation/addon/application-services, score: 0.61} - {ref: solutions/vmware/vsphere, score: 0.55} - {ref: solutions/vmware/vmware-cloud-foundation/addon/advanced-cyber-compliance, score: 0.47} alsoLike: - {ref: posts/how-to-build-your-own-homelab-part-2, score: 1.00} - {ref: posts/how-to-authenticate-with-the-vsphere-supervisor-api, score: 0.75} - {ref: experts/louis-kern, score: 0.61} experts: - {ref: experts/louis-kern, score: 0.61} - {ref: experts/tobias-waelti, score: 0.55} - {ref: experts/yannick-gerber, score: 0.48} search: /en/search.json

{ "apiVersion": "soultec.ch/v1", "kind": "Service", "metadata": { "name": "virtualization-container", "locale": "en", "labels": { "group": "infrastructure", "capability/virtualization": 1.42, "capability/containers": 2.51, "vendor/vmware": 0.98 }, "annotations": { "source": "src/content/services/en/virtualization-container.md", "route": "/en/services/virtualization-container/", "schema": "/nerd/schema/services.json", "markdown": "/en/services/virtualization-container.md" } }, "spec": { "title": "Virtualization", "group": "infrastructure", "audience": [ "enterprise", "provider" ], "order": 10, "tags": [ "virtualization", "containers" ], "vendors": [ "vmware" ], "summary": "Server and desktop virtualization, and a route to containers over a platform your team already knows.", "photoNeed": "Infrastructure work in progress at a customer site or in our lab: hands on hardware, a rack door open, a screen mid-configuration", "stub": false, "draft": false, "sections": [ { "heading": "

Virtualization

", "body": "Virtualizing server and desktop infrastructure improves utilisation, raises availability\nand simplifies management. That has been true for twenty years and still is." }, { "heading": "

The route to containers

", "body": "Containers are where many estates stall, because the obvious answer is a second platform:\nits own operating model, its own monitoring, its own permissions.\n\nThrough vSphere Kubernetes Service, formerly vSphere with Tanzu, the container platform runs\non the virtualization that is already there. If your team knows vSphere, the way in is much\nshorter than it looks." }, { "heading": "

How responsibilities stay where they are

", "body": "The mechanism behind it is the vSphere namespace, and it extends something your team\nalready knows: the resource pool. The vSphere administrator still runs vSphere and assigns\nthe namespace the resources it should get.\n\nFrom there the other side works through the Kubernetes API and `kubectl`, without ever\ntouching the vSphere platform. Development and operations share a boundary rather than a\ntool, and that is the difference from standing up a second platform beside the first.\n\nWorkloads then run either as pods directly on the platform or in their own Kubernetes\nclusters operated as virtual machines." }, { "heading": "

What we do for it

", "body": "Concept and implementation of the server infrastructure, then lifecycle, patching and\nupdates and the tuning for operation. We build the container infrastructure from small to\nlarge. Standardisation is on VMware Cloud Foundation, because an estate built to the\nreference architecture brings fewer surprises at every update." }, { "heading": "

How we start

", "body": "Usually with a proof of concept. Container infrastructure is an area where the requirements\nonly surface once something runs: storage classes, networking and permissions get decided by\nthe first real use case, and then for every one after it." } ] }, "status": { "corpus": 315, "solutions": [ { "ref": "solutions/vmware/vmware-cloud-foundation/vks", "score": "1.00" }, { "ref": "solutions/vmware/vmware-cloud-foundation/addon/application-services", "score": "0.61" }, { "ref": "solutions/vmware/vsphere", "score": "0.55" }, { "ref": "solutions/vmware/vmware-cloud-foundation/addon/advanced-cyber-compliance", "score": "0.47" } ], "alsoLike": [ { "ref": "posts/how-to-build-your-own-homelab-part-2", "score": "1.00" }, { "ref": "posts/how-to-authenticate-with-the-vsphere-supervisor-api", "score": "0.75" }, { "ref": "experts/louis-kern", "score": "0.61" } ], "experts": [ { "ref": "experts/louis-kern", "score": "0.61" }, { "ref": "experts/tobias-waelti", "score": "0.55" }, { "ref": "experts/yannick-gerber", "score": "0.48" } ], "search": "/en/search.json" }}

apiVersion = "soultec.ch/v1"kind = "Service"[metadata]name = "virtualization-container"locale = "en"[metadata.labels]group = "infrastructure""capability/virtualization" = 1.42"capability/containers" = 2.51"vendor/vmware" = 0.98[metadata.annotations]source = "src/content/services/en/virtualization-container.md"route = "/en/services/virtualization-container/"schema = "/nerd/schema/services.json"markdown = "/en/services/virtualization-container.md"[spec]title = "Virtualization"group = "infrastructure"audience = ["enterprise", "provider"]order = 10tags = ["virtualization", "containers"]vendors = ["vmware"]summary = "Server and desktop virtualization, and a route to containers over a platform your team already knows."photoNeed = "Infrastructure work in progress at a customer site or in our lab: hands on hardware, a rack door open, a screen mid-configuration"stub = falsedraft = false[[spec.sections]]heading = "

Virtualization

"body = '''Virtualizing server and desktop infrastructure improves utilisation, raises availabilityand simplifies management. That has been true for twenty years and still is.'''[[spec.sections]]heading = "

The route to containers

"body = '''Containers are where many estates stall, because the obvious answer is a second platform:its own operating model, its own monitoring, its own permissions.Through vSphere Kubernetes Service, formerly vSphere with Tanzu, the container platform runson the virtualization that is already there. If your team knows vSphere, the way in is muchshorter than it looks.'''[[spec.sections]]heading = "

How responsibilities stay where they are

"body = '''The mechanism behind it is the vSphere namespace, and it extends something your teamalready knows: the resource pool. The vSphere administrator still runs vSphere and assignsthe namespace the resources it should get.From there the other side works through the Kubernetes API and `kubectl`, without evertouching the vSphere platform. Development and operations share a boundary rather than atool, and that is the difference from standing up a second platform beside the first.Workloads then run either as pods directly on the platform or in their own Kubernetesclusters operated as virtual machines.'''[[spec.sections]]heading = "

What we do for it

"body = '''Concept and implementation of the server infrastructure, then lifecycle, patching andupdates and the tuning for operation. We build the container infrastructure from small tolarge. Standardisation is on VMware Cloud Foundation, because an estate built to thereference architecture brings fewer surprises at every update.'''[[spec.sections]]heading = "

How we start

"body = '''Usually with a proof of concept. Container infrastructure is an area where the requirementsonly surface once something runs: storage classes, networking and permissions get decided bythe first real use case, and then for every one after it.'''[status]corpus = 315search = "/en/search.json"[[status.solutions]]ref = "solutions/vmware/vmware-cloud-foundation/vks"score = "1.00"[[status.solutions]]ref = "solutions/vmware/vmware-cloud-foundation/addon/application-services"score = "0.61"[[status.solutions]]ref = "solutions/vmware/vsphere"score = "0.55"[[status.solutions]]ref = "solutions/vmware/vmware-cloud-foundation/addon/advanced-cyber-compliance"score = "0.47"[[status.alsoLike]]ref = "posts/how-to-build-your-own-homelab-part-2"score = "1.00"[[status.alsoLike]]ref = "posts/how-to-authenticate-with-the-vsphere-supervisor-api"score = "0.75"[[status.alsoLike]]ref = "experts/louis-kern"score = "0.61"[[status.experts]]ref = "experts/louis-kern"score = "0.61"[[status.experts]]ref = "experts/tobias-waelti"score = "0.55"[[status.experts]]ref = "experts/yannick-gerber"score = "0.48"

<?xml version="1.0" encoding="UTF-8"?><manifest kind="Service"> <apiVersion>soultec.ch/v1</apiVersion> <metadata> <name>virtualization-container</name> <locale>en</locale> <labels> <group>infrastructure</group> <entry key="capability/virtualization">1.42</entry> <entry key="capability/containers">2.51</entry> <entry key="vendor/vmware">0.98</entry> </labels> <annotations> <source>src/content/services/en/virtualization-container.md</source> <route>/en/services/virtualization-container/</route> <schema>/nerd/schema/services.json</schema> <markdown>/en/services/virtualization-container.md</markdown> </annotations> </metadata> <spec> <title>Virtualization</title> <group>infrastructure</group> <audience> <item>enterprise</item> <item>provider</item> </audience> <order>10</order> <tags> <item>virtualization</item> <item>containers</item> </tags> <vendors> <item>vmware</item> </vendors> <summary>Server and desktop virtualization, and a route to containers over a platform your team already knows.</summary> <photoNeed>Infrastructure work in progress at a customer site or in our lab: hands on hardware, a rack door open, a screen mid-configuration</photoNeed> <stub>false</stub> <draft>false</draft> <sections> <section> <heading>

Virtualization

</heading> <body>Virtualizing server and desktop infrastructure improves utilisation, raises availabilityand simplifies management. That has been true for twenty years and still is. </body> </section> <section> <heading>

The route to containers

</heading> <body>Containers are where many estates stall, because the obvious answer is a second platform:its own operating model, its own monitoring, its own permissions.Through vSphere Kubernetes Service, formerly vSphere with Tanzu, the container platform runson the virtualization that is already there. If your team knows vSphere, the way in is muchshorter than it looks. </body> </section> <section> <heading>

How responsibilities stay where they are

</heading> <body>The mechanism behind it is the vSphere namespace, and it extends something your teamalready knows: the resource pool. The vSphere administrator still runs vSphere and assignsthe namespace the resources it should get.From there the other side works through the Kubernetes API and `kubectl`, without evertouching the vSphere platform. Development and operations share a boundary rather than atool, and that is the difference from standing up a second platform beside the first.Workloads then run either as pods directly on the platform or in their own Kubernetesclusters operated as virtual machines. </body> </section> <section> <heading>

What we do for it

</heading> <body>Concept and implementation of the server infrastructure, then lifecycle, patching andupdates and the tuning for operation. We build the container infrastructure from small tolarge. Standardisation is on VMware Cloud Foundation, because an estate built to thereference architecture brings fewer surprises at every update. </body> </section> <section> <heading>

How we start

</heading> <body>Usually with a proof of concept. Container infrastructure is an area where the requirementsonly surface once something runs: storage classes, networking and permissions get decided bythe first real use case, and then for every one after it. </body> </section> </sections> </spec> <status> <corpus>315</corpus> <solutions> <item> <ref>solutions/vmware/vmware-cloud-foundation/vks</ref> <score>1.00</score> </item> <item> <ref>solutions/vmware/vmware-cloud-foundation/addon/application-services</ref> <score>0.61</score> </item> <item> <ref>solutions/vmware/vsphere</ref> <score>0.55</score> </item> <item> <ref>solutions/vmware/vmware-cloud-foundation/addon/advanced-cyber-compliance</ref> <score>0.47</score> </item> </solutions> <alsoLike> <item> <ref>posts/how-to-build-your-own-homelab-part-2</ref> <score>1.00</score> </item> <item> <ref>posts/how-to-authenticate-with-the-vsphere-supervisor-api</ref> <score>0.75</score> </item> <item> <ref>experts/louis-kern</ref> <score>0.61</score> </item> </alsoLike> <experts> <item> <ref>experts/louis-kern</ref> <score>0.61</score> </item> <item> <ref>experts/tobias-waelti</ref> <score>0.55</score> </item> <item> <ref>experts/yannick-gerber</ref> <score>0.48</score> </item> </experts> <search>/en/search.json</search> </status></manifest>

# Code generated by the soultec.ch build. DO NOT EDIT.import jsonPAGE = { "apiVersion": "soultec.ch/v1", "kind": "Service", "metadata": { "name": "virtualization-container", "locale": "en", "labels": { "group": "infrastructure", "capability/virtualization": 1.42, "capability/containers": 2.51, "vendor/vmware": 0.98, }, "annotations": { "source": "src/content/services/en/virtualization-container.md", "route": "/en/services/virtualization-container/", "schema": "/nerd/schema/services.json", "markdown": "/en/services/virtualization-container.md", }, }, "spec": { "title": "Virtualization", "group": "infrastructure", "audience": ["enterprise", "provider"], "order": 10, "tags": ["virtualization", "containers"], "vendors": ["vmware"], "summary": "Server and desktop virtualization, and a route to containers over a platform your team already knows.", "photoNeed": "Infrastructure work in progress at a customer site or in our lab: hands on hardware, a rack door open, a screen mid-configuration", "stub": False, "draft": False, "sections": [ { "heading": "

Virtualization

", "body": ( "Virtualizing server and desktop infrastructure improves utilisation, raises availability\n" "and simplifies management. That has been true for twenty years and still is." ), }, { "heading": "

The route to containers

", "body": ( "Containers are where many estates stall, because the obvious answer is a second platform:\n" "its own operating model, its own monitoring, its own permissions.\n" "\n" "Through vSphere Kubernetes Service, formerly vSphere with Tanzu, the container platform runs\n" "on the virtualization that is already there. If your team knows vSphere, the way in is much\n" "shorter than it looks." ), }, { "heading": "

How responsibilities stay where they are

", "body": ( "The mechanism behind it is the vSphere namespace, and it extends something your team\n" "already knows: the resource pool. The vSphere administrator still runs vSphere and assigns\n" "the namespace the resources it should get.\n" "\n" "From there the other side works through the Kubernetes API and `kubectl`, without ever\n" "touching the vSphere platform. Development and operations share a boundary rather than a\n" "tool, and that is the difference from standing up a second platform beside the first.\n" "\n" "Workloads then run either as pods directly on the platform or in their own Kubernetes\n" "clusters operated as virtual machines." ), }, { "heading": "

What we do for it

", "body": ( "Concept and implementation of the server infrastructure, then lifecycle, patching and\n" "updates and the tuning for operation. We build the container infrastructure from small to\n" "large. Standardisation is on VMware Cloud Foundation, because an estate built to the\n" "reference architecture brings fewer surprises at every update." ), }, { "heading": "

How we start

", "body": ( "Usually with a proof of concept. Container infrastructure is an area where the requirements\n" "only surface once something runs: storage classes, networking and permissions get decided by\n" "the first real use case, and then for every one after it." ), }, ], }, "status": { "corpus": 315, "solutions": [ { "ref": "solutions/vmware/vmware-cloud-foundation/vks", "score": "1.00", }, { "ref": "solutions/vmware/vmware-cloud-foundation/addon/application-services", "score": "0.61", }, { "ref": "solutions/vmware/vsphere", "score": "0.55", }, { "ref": "solutions/vmware/vmware-cloud-foundation/addon/advanced-cyber-compliance", "score": "0.47", }, ], "alsoLike": [ { "ref": "posts/how-to-build-your-own-homelab-part-2", "score": "1.00", }, { "ref": "posts/how-to-authenticate-with-the-vsphere-supervisor-api", "score": "0.75", }, { "ref": "experts/louis-kern", "score": "0.61", }, ], "experts": [ { "ref": "experts/louis-kern", "score": "0.61", }, { "ref": "experts/tobias-waelti", "score": "0.55", }, { "ref": "experts/yannick-gerber", "score": "0.48", }, ], "search": "/en/search.json", },}if __name__ == "__main__": print(json.dumps(PAGE, indent=2, ensure_ascii=False))

# Code generated by the soultec.ch build. DO NOT EDIT.$Page = [ordered]@{ apiVersion = 'soultec.ch/v1' kind = 'Service' metadata = [ordered]@{ name = 'virtualization-container' locale = 'en' labels = [ordered]@{ group = 'infrastructure' 'capability/virtualization' = 1.42 'capability/containers' = 2.51 'vendor/vmware' = 0.98 } annotations = [ordered]@{ source = 'src/content/services/en/virtualization-container.md' route = '/en/services/virtualization-container/' schema = '/nerd/schema/services.json' markdown = '/en/services/virtualization-container.md' } } spec = [ordered]@{ title = 'Virtualization' group = 'infrastructure' audience = @('enterprise', 'provider') order = 10 tags = @('virtualization', 'containers') vendors = @('vmware') summary = 'Server and desktop virtualization, and a route to containers over a platform your team already knows.' photoNeed = 'Infrastructure work in progress at a customer site or in our lab: hands on hardware, a rack door open, a screen mid-configuration' stub = $false draft = $false sections = @( [ordered]@{ heading = '

Virtualization

' body = @'Virtualizing server and desktop infrastructure improves utilisation, raises availabilityand simplifies management. That has been true for twenty years and still is.'@ } [ordered]@{ heading = '

The route to containers

' body = @'Containers are where many estates stall, because the obvious answer is a second platform:its own operating model, its own monitoring, its own permissions.Through vSphere Kubernetes Service, formerly vSphere with Tanzu, the container platform runson the virtualization that is already there. If your team knows vSphere, the way in is muchshorter than it looks.'@ } [ordered]@{ heading = '

How responsibilities stay where they are

' body = @'The mechanism behind it is the vSphere namespace, and it extends something your teamalready knows: the resource pool. The vSphere administrator still runs vSphere and assignsthe namespace the resources it should get.From there the other side works through the Kubernetes API and `kubectl`, without evertouching the vSphere platform. Development and operations share a boundary rather than atool, and that is the difference from standing up a second platform beside the first.Workloads then run either as pods directly on the platform or in their own Kubernetesclusters operated as virtual machines.'@ } [ordered]@{ heading = '

What we do for it

' body = @'Concept and implementation of the server infrastructure, then lifecycle, patching andupdates and the tuning for operation. We build the container infrastructure from small tolarge. Standardisation is on VMware Cloud Foundation, because an estate built to thereference architecture brings fewer surprises at every update.'@ } [ordered]@{ heading = '

How we start

' body = @'Usually with a proof of concept. Container infrastructure is an area where the requirementsonly surface once something runs: storage classes, networking and permissions get decided bythe first real use case, and then for every one after it.'@ } ) } status = [ordered]@{ corpus = 315 solutions = @( [ordered]@{ ref = 'solutions/vmware/vmware-cloud-foundation/vks' score = '1.00' } [ordered]@{ ref = 'solutions/vmware/vmware-cloud-foundation/addon/application-services' score = '0.61' } [ordered]@{ ref = 'solutions/vmware/vsphere' score = '0.55' } [ordered]@{ ref = 'solutions/vmware/vmware-cloud-foundation/addon/advanced-cyber-compliance' score = '0.47' } ) alsoLike = @( [ordered]@{ ref = 'posts/how-to-build-your-own-homelab-part-2' score = '1.00' } [ordered]@{ ref = 'posts/how-to-authenticate-with-the-vsphere-supervisor-api' score = '0.75' } [ordered]@{ ref = 'experts/louis-kern' score = '0.61' } ) experts = @( [ordered]@{ ref = 'experts/louis-kern' score = '0.61' } [ordered]@{ ref = 'experts/tobias-waelti' score = '0.55' } [ordered]@{ ref = 'experts/yannick-gerber' score = '0.48' } ) search = '/en/search.json' }}$Page | ConvertTo-Json -Depth 32

// Code generated by the soultec.ch build. DO NOT EDIT.package mainimport ( "encoding/json" "os")var page = map[string]any{ "apiVersion": "soultec.ch/v1", "kind": "Service", "metadata": map[string]any{ "name": "virtualization-container", "locale": "en", "labels": map[string]any{ "group": "infrastructure", "capability/virtualization": 1.42, "capability/containers": 2.51, "vendor/vmware": 0.98, }, "annotations": map[string]any{ "source": "src/content/services/en/virtualization-container.md", "route": "/en/services/virtualization-container/", "schema": "/nerd/schema/services.json", "markdown": "/en/services/virtualization-container.md", }, }, "spec": map[string]any{ "title": "Virtualization", "group": "infrastructure", "audience": []any{"enterprise", "provider"}, "order": 10, "tags": []any{"virtualization", "containers"}, "vendors": []any{"vmware"}, "summary": "Server and desktop virtualization, and a route to containers over a platform your team already knows.", "photoNeed": "Infrastructure work in progress at a customer site or in our lab: hands on hardware, a rack door open, a screen mid-configuration", "stub": false, "draft": false, "sections": []any{ map[string]any{ "heading": "

Virtualization

", "body": "Virtualizing server and desktop infrastructure improves utilisation, raises availability\n" + "and simplifies management. That has been true for twenty years and still is.", }, map[string]any{ "heading": "

The route to containers

", "body": "Containers are where many estates stall, because the obvious answer is a second platform:\n" + "its own operating model, its own monitoring, its own permissions.\n" + "\n" + "Through vSphere Kubernetes Service, formerly vSphere with Tanzu, the container platform runs\n" + "on the virtualization that is already there. If your team knows vSphere, the way in is much\n" + "shorter than it looks.", }, map[string]any{ "heading": "

How responsibilities stay where they are

", "body": "The mechanism behind it is the vSphere namespace, and it extends something your team\n" + "already knows: the resource pool. The vSphere administrator still runs vSphere and assigns\n" + "the namespace the resources it should get.\n" + "\n" + "From there the other side works through the Kubernetes API and `kubectl`, without ever\n" + "touching the vSphere platform. Development and operations share a boundary rather than a\n" + "tool, and that is the difference from standing up a second platform beside the first.\n" + "\n" + "Workloads then run either as pods directly on the platform or in their own Kubernetes\n" + "clusters operated as virtual machines.", }, map[string]any{ "heading": "

What we do for it

", "body": "Concept and implementation of the server infrastructure, then lifecycle, patching and\n" + "updates and the tuning for operation. We build the container infrastructure from small to\n" + "large. Standardisation is on VMware Cloud Foundation, because an estate built to the\n" + "reference architecture brings fewer surprises at every update.", }, map[string]any{ "heading": "

How we start

", "body": "Usually with a proof of concept. Container infrastructure is an area where the requirements\n" + "only surface once something runs: storage classes, networking and permissions get decided by\n" + "the first real use case, and then for every one after it.", }, }, }, "status": map[string]any{ "corpus": 315, "solutions": []any{ map[string]any{ "ref": "solutions/vmware/vmware-cloud-foundation/vks", "score": "1.00", }, map[string]any{ "ref": "solutions/vmware/vmware-cloud-foundation/addon/application-services", "score": "0.61", }, map[string]any{ "ref": "solutions/vmware/vsphere", "score": "0.55", }, map[string]any{ "ref": "solutions/vmware/vmware-cloud-foundation/addon/advanced-cyber-compliance", "score": "0.47", }, }, "alsoLike": []any{ map[string]any{ "ref": "posts/how-to-build-your-own-homelab-part-2", "score": "1.00", }, map[string]any{ "ref": "posts/how-to-authenticate-with-the-vsphere-supervisor-api", "score": "0.75", }, map[string]any{ "ref": "experts/louis-kern", "score": "0.61", }, }, "experts": []any{ map[string]any{ "ref": "experts/louis-kern", "score": "0.61", }, map[string]any{ "ref": "experts/tobias-waelti", "score": "0.55", }, map[string]any{ "ref": "experts/yannick-gerber", "score": "0.48", }, }, "search": "/en/search.json", },}func main() { enc := json.NewEncoder(os.Stdout) enc.SetEscapeHTML(false) enc.SetIndent("", " ") if err := enc.Encode(page); err != nil { os.Exit(1) }}

// Code generated by the soultec.ch build. DO NOT EDIT.const page = { apiVersion: "soultec.ch/v1", kind: "Service", metadata: { name: "virtualization-container", locale: "en", labels: { group: "infrastructure", "capability/virtualization": 1.42, "capability/containers": 2.51, "vendor/vmware": 0.98, }, annotations: { source: "src/content/services/en/virtualization-container.md", route: "/en/services/virtualization-container/", schema: "/nerd/schema/services.json", markdown: "/en/services/virtualization-container.md", }, }, spec: { title: "Virtualization", group: "infrastructure", audience: ["enterprise", "provider"], order: 10, tags: ["virtualization", "containers"], vendors: ["vmware"], summary: "Server and desktop virtualization, and a route to containers over a platform your team already knows.", photoNeed: "Infrastructure work in progress at a customer site or in our lab: hands on hardware, a rack door open, a screen mid-configuration", stub: false, draft: false, sections: [ { heading: "

Virtualization

", body: "Virtualizing server and desktop infrastructure improves utilisation, raises availability\n" + "and simplifies management. That has been true for twenty years and still is.", }, { heading: "

The route to containers

", body: "Containers are where many estates stall, because the obvious answer is a second platform:\n" + "its own operating model, its own monitoring, its own permissions.\n" + "\n" + "Through vSphere Kubernetes Service, formerly vSphere with Tanzu, the container platform runs\n" + "on the virtualization that is already there. If your team knows vSphere, the way in is much\n" + "shorter than it looks.", }, { heading: "

How responsibilities stay where they are

", body: "The mechanism behind it is the vSphere namespace, and it extends something your team\n" + "already knows: the resource pool. The vSphere administrator still runs vSphere and assigns\n" + "the namespace the resources it should get.\n" + "\n" + "From there the other side works through the Kubernetes API and `kubectl`, without ever\n" + "touching the vSphere platform. Development and operations share a boundary rather than a\n" + "tool, and that is the difference from standing up a second platform beside the first.\n" + "\n" + "Workloads then run either as pods directly on the platform or in their own Kubernetes\n" + "clusters operated as virtual machines.", }, { heading: "

What we do for it

", body: "Concept and implementation of the server infrastructure, then lifecycle, patching and\n" + "updates and the tuning for operation. We build the container infrastructure from small to\n" + "large. Standardisation is on VMware Cloud Foundation, because an estate built to the\n" + "reference architecture brings fewer surprises at every update.", }, { heading: "

How we start

", body: "Usually with a proof of concept. Container infrastructure is an area where the requirements\n" + "only surface once something runs: storage classes, networking and permissions get decided by\n" + "the first real use case, and then for every one after it.", }, ], }, status: { corpus: 315, solutions: [ { ref: "solutions/vmware/vmware-cloud-foundation/vks", score: "1.00", }, { ref: "solutions/vmware/vmware-cloud-foundation/addon/application-services", score: "0.61", }, { ref: "solutions/vmware/vsphere", score: "0.55", }, { ref: "solutions/vmware/vmware-cloud-foundation/addon/advanced-cyber-compliance", score: "0.47", }, ], alsoLike: [ { ref: "posts/how-to-build-your-own-homelab-part-2", score: "1.00", }, { ref: "posts/how-to-authenticate-with-the-vsphere-supervisor-api", score: "0.75", }, { ref: "experts/louis-kern", score: "0.61", }, ], experts: [ { ref: "experts/louis-kern", score: "0.61", }, { ref: "experts/tobias-waelti", score: "0.55", }, { ref: "experts/yannick-gerber", score: "0.48", }, ], search: "/en/search.json", },};console.log(JSON.stringify(page, null, 2));

# 82 lines · YAML · validated at build# 112 lines · JSON · validated at build# 124 lines · TOML · validated at build# 142 lines · XML · validated at build# 140 lines · Python · read back at build, equals the JSON record# 137 lines · PowerShell · read back at build, equals the JSON record# 142 lines · Go · read back at build, equals the JSON record# 127 lines · JavaScript · read back at build, equals the JSON record · served at /en/services/virtualization-container.md

Service · infrastructure

Virtualization

Server and desktop virtualization, and a route to containers over a platform your team already knows.

Topics Virtualization 1.42 Containers 2.51

Vendors VMware 0.98

04Solutions

02Capabilities

01Vendors

315Corpus

photograph wantedInfrastructure work in progress at a customer site or in our lab: hands on hardware, a rack door open, a screen mid-configuration

Virtualization

Virtualizing server and desktop infrastructure improves utilisation, raises availability and simplifies management. That has been true for twenty years and still is.

The route to containers

Containers are where many estates stall, because the obvious answer is a second platform: its own operating model, its own monitoring, its own permissions.

Through vSphere Kubernetes Service, formerly vSphere with Tanzu, the container platform runs on the virtualization that is already there. If your team knows vSphere, the way in is much shorter than it looks.

How responsibilities stay where they are

The mechanism behind it is the vSphere namespace, and it extends something your team already knows: the resource pool. The vSphere administrator still runs vSphere and assigns the namespace the resources it should get.

From there the other side works through the Kubernetes API and kubectl, without ever touching the vSphere platform. Development and operations share a boundary rather than a tool, and that is the difference from standing up a second platform beside the first.

Workloads then run either as pods directly on the platform or in their own Kubernetes clusters operated as virtual machines.

What we do for it

Concept and implementation of the server infrastructure, then lifecycle, patching and updates and the tuning for operation. We build the container infrastructure from small to large. Standardisation is on VMware Cloud Foundation, because an estate built to the reference architecture brings fewer surprises at every update.

How we start

Usually with a proof of concept. Container infrastructure is an area where the requirements only surface once something runs: storage classes, networking and permissions get decided by the first real use case, and then for every one after it.

Experts for this

Louis Kern

Senior System Engineer

ContainersVirtualization

0.61

Tobias Wälti

Senior System Engineer

ContainersVirtualization

0.55

Yannick Gerber

Senior Solution Architect

ContainersVirtualization

0.48

Maybe you? Take a look at our open roles.

Post 1.00

Build your own Homelab – Part 2

8 May 2023

Post 0.75

Authenticate with the vSphere Supervisor API

29 Jul 2026

Person 0.61

Virtualization

The route to containers

How responsibilities stay where they are

What we do for it

How we start

Virtualization

The route to containers

How responsibilities stay where they are

What we do for it

How we start

Virtualization

The route to containers

How responsibilities stay where they are

What we do for it

How we start

Virtualization

The route to containers

How responsibilities stay where they are

What we do for it

How we start

Virtualization

The route to containers

How responsibilities stay where they are

What we do for it

How we start

Virtualization

The route to containers

How responsibilities stay where they are

What we do for it

How we start

Virtualization

The route to containers

How responsibilities stay where they are

What we do for it

How we start

Virtualization

The route to containers

How responsibilities stay where they are

What we do for it

How we start

Virtualization

Virtualization

The route to containers

How responsibilities stay where they are

What we do for it

How we start

Experts for this

Louis Kern

Tobias Wälti

Yannick Gerber

You might also like

Build your own Homelab – Part 2

Authenticate with the vSphere Supervisor API

Louis Kern