Manually creating a Virtual Server base image
Objective: Configure a Virtual Server instance to serve as the source for subsequent Virtual Server deployment instances.
Overview: CoreWeave offers a variety of operating system base images, enhanced to run on CoreWeave Cloud, via our vd-images namespace. This guide details using one of these base images, customizing it with desired changes, and using it as a source disk for subsequent machines in a private tenant namespace.
Deploy source Virtual Server
Be sure to review Getting Started and the kubectl Virtual Server deployment method before starting this guide.
First, we will deploy a Windows Virtual Server using a reference YAML. This will serve as the source disk for our subsequent instances:
$ kubectl create -f virtual-server-windows-source.yaml
apiVersion: virtualservers.coreweave.com/v1alpha1kind: VirtualServermetadata:name: vs-windows10-sourcespec:region: LAS1os:type: windowsresources:gpu:type: Quadro_RTX_4000count: 1cpu:count: 3memory: 16Gistorage:root:size: 80GistorageClassName: block-nvme-las1source:pvc:namespace: vd-images# Reference querying source image here:# https://docs.coreweave.com/virtual-servers/root-disk-lifecycle-management/exporting-coreweave-images-to-a-writable-pvc#identifying-source-imagename: win10-master-20210813-las1# Set user name and paswordusers:- username:password:network:public: truedirectAttachLoadBalancerIP: trueinitializeRunning: true
Note this instance exists in LAS1 - subsequent instances should match this region, or will suffer extended spin-up times. A base disk can also be cloned across regions.
We can monitor the Virtual Server spinning up with kubectl get pods --watch
Once our VS has reached "Running" status, we can get an External IP to connect to it with kubectl get vs
Allow ~5 minutes after "Running" status for the Virtual Server to complete initial start procedures.
Customizing the Virtual Server Instance
Once the Virtual Server is ready, we can use the External IP to connect to it via RDP (mstsc
):
Or via OpenSSH:
Or even via Console (useful for instances where a Public IP is not desired) using virtctl console vs-windows10-source
:
Review Remote Access and Control for more information on virtctl
When customization of the instance is complete, stop it using virtctl
(virtctl stop vs-windows10-source
). Note that shutting down from within the operating system will cause the instance to start back up with a new pod - the instance must be shutdown using virtctl
.
Using kubectl get vs
, we can confirm Started: False
:
Referencing source PVC in a new instance
We can see that the PVC created along with our source Virtual Server persists with it shut off:
We will reference this PVC to create a new Virtual Server:
apiVersion: virtualservers.coreweave.com/v1alpha1kind: VirtualServermetadata:name: vs-windows10-newspec:region: LAS1os:type: windowsresources:gpu:type: Quadro_RTX_4000count: 1cpu:count: 3memory: 16Gistorage:root:size: 80GistorageClassName: block-nvme-las1source:pvc:# Reference your tenant here# Reference your source VS PVC herenamespace: tenant-<name>name: vs-windows10-source# Set user name and paswordusers:- username:password:network:public: truedirectAttachLoadBalancerIP: trueinitializeRunning: true
Note our namespace and PVC name has changed to match our source VS.
The root disk of vs-windows10-new
will be automatically cloned from vs-windows10-source
.
Cloning source disk PVC
The root disk we are using to clone new instances is tied to the Virtual Server with which it was created. If we wish to delete our Virtual Server vs-windows10-source
, but retain its root disk as a clone source, we will need to clone the PVC.
Using pvc-clone.sh
, located in CoreWeave's Kubernetes Cloud GitHub repository, we will clone our Virtual Server's root disk:
Usage: ./pvc-clone.sh <source vmi> <destination pvc name>$./pvc-clone.sh vs-windows10-source windows10-base-disk
This will clone a PVC within the same region in which it was created.
We can now safely delete our Virtual Server with k delete vs vs-windows10-source
:
With k get pvc
, we can see our original Virtual Server PVC is now deleted, and only the clone remains:
We'll adjust our Virtual Server spec to suit:
source:pvc:# Reference your tenant here# Reference your source VS PVC herenamespace: tenant-<name>name: windows10-base-disk-20210907-block-las1