Skip to main content

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

tip

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

virtual-server-windows-source.yaml
apiVersion: virtualservers.coreweave.com/v1alpha1
kind: VirtualServer
metadata:
name: vs-windows10-source
spec:
region: LAS1
os:
type: windows
resources:
gpu:
type: Quadro_RTX_4000
count: 1
cpu:
count: 3
memory: 16Gi
storage:
root:
size: 80Gi
storageClassName: block-nvme-las1
source:
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-image
name: win10-master-20210813-las1
# Set user name and pasword
users:
- username:
password:
network:
public: true
directAttachLoadBalancerIP: true
initializeRunning: true
important

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

note

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:

tip

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:

virtual-server-windows-new.yaml
apiVersion: virtualservers.coreweave.com/v1alpha1
kind: VirtualServer
metadata:
name: vs-windows10-new
spec:
region: LAS1
os:
type: windows
resources:
gpu:
type: Quadro_RTX_4000
count: 1
cpu:
count: 3
memory: 16Gi
storage:
root:
size: 80Gi
storageClassName: block-nvme-las1
source:
pvc:
# Reference your tenant here
# Reference your source VS PVC here
namespace: tenant-<name>
name: vs-windows10-source
# Set user name and pasword
users:
- username:
password:
network:
public: true
directAttachLoadBalancerIP: true
initializeRunning: true
note

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
important

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:

virtual-server-windows-new.yaml
      source:
pvc:
# Reference your tenant here
# Reference your source VS PVC here
namespace: tenant-<name>
name: windows10-base-disk-20210907-block-las1