Additional Features
Learn more about other configurations available for Virtual Servers.
Below are some additional features Virtual Servers offering even finer-grained control and configuration options for niche use cases.
Note
All additional features discussed in this document must be configured using the YAML editor if deploying a Virtual Server using the Cloud UI.
In many use cases, such as data processing or pixel-streaming, Virtual Servers do not need to be long-living, and in fact, they are best used ephemerally. In these instances, leveraging ephemeral root disks will speed up instantiation, as well as lower hosting costs.
- Ephemeral root disks don't require a new root volume to be allocated, removing this time-consuming step from the instantiation process to make for faster boot times.⏰
- Removing ephemeral root disks means they no longer need to be hosted, which reduces hosting costs overall.✨
- Ephemeral disks are still writeable; modifications made at run-time are temporarily stored in the ephemeral disk of the active node. All changes written to the root disk are only lost when the Virtual Server is shut down or restarted.✍
Note
A shared filesystem volume, NFS, SMB, or Object storage should be used to store persistent data in data-processing use cases.
Cloud UI
CLI
Terraform
When configuring an ephemeral root storage disk on the Cloud UI, the source image is cloned into a
ReadOnlyMany type volume, as shown in the example below. Use the Cloud UI YAML editor to incorporate the configuration into the Virtual Server's manifest.---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: image-rox
spec:
accessModes:
- ReadOnlyMany
dataSource:
kind: PersistentVolumeClaim
name: <source-root-disk-pvc> # This name will be the same name as a DataVolume/VirtualServer used as the source.
resources:
requests:
storage: 40Gi # Must match the size of the source volume
storageClassName: block-nvme-ord1
volumeMode: Block
---
apiVersion: virtualservers.coreweave.com/v1alpha1
kind: VirtualServer
metadata:
name: example-vs
spec:
region: ORD1
os:
type: linux
resources:
gpu:
type: Quadro_RTX_4000
count: 1
cpu:
count: 4
memory: 16Gi
storage:
root:
size: 40Gi
storageClassName: block-nvme-ord1
ephemeral: true
source:
pvc:
namespace: tenant-example # Replace with your namespace
name: image-rox
# Change user name and pasword
# User is on the sudoers list
# users:
# - username: SET YOUR USERNAME HERE
# password: SET YOUR PASSWORD HERE
# To use key-based authentication replace and uncomment ssh-rsa below with your public ssh key
# sshpublickey: |
# ssh-rsa AAAAB3NzaC1yc2EAAAA ... user@hostname
network:
public: false
Additional Resources
When configuring an ephemeral root storage disk, the source image is cloned into a
ReadOnlyMany type volume, as shown in the example below.---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: image-rox
spec:
accessModes:
- ReadOnlyMany
dataSource:
kind: PersistentVolumeClaim
name: <source-root-disk-pvc> # This name will be the same name as a DataVolume/VirtualServer used as the source.
resources:
requests:
storage: 40Gi # Must match the size of the source volume
storageClassName: block-nvme-ord1
volumeMode: Block
---
apiVersion: virtualservers.coreweave.com/v1alpha1
kind: VirtualServer
metadata:
name: example-vs
spec:
region: ORD1
os:
type: linux
resources:
gpu:
type: Quadro_RTX_4000
count: 1
cpu:
count: 4
memory: 16Gi
storage:
root:
size: 40Gi
storageClassName: block-nvme-ord1
ephemeral: true
source:
pvc:
namespace: tenant-example # Replace with your namespace
name: image-rox
# Change user name and pasword
# User is on the sudoers list
# users:
# - username: SET YOUR USERNAME HERE
# password: SET YOUR PASSWORD HERE
# To use key-based authentication replace and uncomment ssh-rsa below with your public ssh key
# sshpublickey: |
# ssh-rsa AAAAB3NzaC1yc2EAAAA ... user@hostname
network:
public: false
Additional Resources
Deployment method: Terraform
Note
It is not currently possible to deploy ephemeral root disks using the Terraform module. See the CLI option. Alternatively, you may extend the Virtual Server Terraform module yourself.
Configuring the RunStrategy for the Virtual Server determines what CoreWeave's Virtual Server orchestration infrastructure will do on instance crash or shutdown. The default RunStrategy is
RerunOnFailure, meaning Kubevirt will not restart the system when someone issues a shutdown command from the OS.
All available RunStrategy options:Option | Description |
|---|---|
Always | A Virtual Server will always be present. If the Virtual Server crashed, a new one will be spawned. |
RerunOnFailure | Default. A VirtualMachineInstance will be respawned if the previous instance failed in an error state. It will not be re-created if the guest stopped successfully (e.g. shut down from inside guest). |
Manual | The presence of a VirtualMachineInstance or lack thereof is controlled exclusively by the start/stop/restart VirtualMachine subresource endpoints. |
Halted | No VirtualMachineInstance will be present. If a guest is already running, it will be stopped. This is the same behavior as spec.running: false. |
Cloud UI
CLI
Terraform
To change the default RunStrategy for a Virtual Server, define the strategy to use in the
spec.runStrategy field using the YAML editor.Field name | Field type | Description |
|---|---|---|
runStrategy |
Example in plain text:
runStrategy: Always
To change the default RunStrategy for a Virtual Server, define the strategy to use in the
spec.runStrategy field.Field name | Field type | Description |
|---|---|---|
runStrategy |
Example in plain text:
runStrategy: Always
Note
It is not currently possible to configure runStrategy through Terraform. This feature may be configured in conjunction with the Cloud UI or Kubernetes CLI. Alternatively, you may extend the Virtual Server Terraform module yourself.
Enables virtio-transitional to support compatibility with older guest Operating Systems. The default value is
false. Cloud UI
CLI
Terraform
Note
It is not currently possible to configure useVirtioTransitional through Terraform. This feature may be configured in conjunction with the Kubernetes CLI. Alternatively, you may extend the Virtual Server Terraform module yourself.
Specifies the number in seconds before the guest is killed, allowing the operating system to be shut down gracefully. The default value for Linux-based systems is 60. Windows shutdown may take some time so the default value is 300s. "A 0 value for the grace period option means that the virtual machine should not have a grace period observed during shutdown."
Cloud UI
CLI
Terraform
Deployment method: Terraform
Note
It is not currently possible to configure terminationGracePeriodSeconds through Terraform. This feature may be configured in conjunction with the Cloud UI or Kubernetes CLI. Alternatively, you may extend the Virtual Server Terraform module yourself.
Determines whether or not the Virtual Server should be started as soon as it is created and initialized.
Cloud UI
CLI
Terraform
Deployment method: Terraform
Note
It is not currently possible to configure
initializeRunning through the Cloud UI. This feature may be configured in conjunction with the Kubernetes CLI. Alternatively, you may extend the Virtual Server Terraform module yourself.Floating services, sometimes called floating IPs, allows users to create their own load balancing Services with static IP addresses, which can then be used to configure custom DNS or custom IP addresses.
Cloud UI
CLI
Terraform
Open the YAML editor to configure floating services under the
.network.floatingIPs stanza . This field is a list of load balancer Service names. If configured, the Virtual Server will be assigned floating IPs from the load balancer IP of each service.Field name | Field type | Description |
|---|---|---|
network.floatingIPs | List | A list of Service references to be added as floating IPs |
network.floatingIPs[ ].serviceName | String | The name of the Service
|
Example in plain text:
network:
floatingIPs:
- <svc-name>
To deploy a Floating IP service, configure the following fields.
Field name | Field type | Description |
|---|---|---|
network.floatingIPs | List | A list of Service references to be added as floating IPs |
network.floatingIPs[ ].serviceName | String | The name of the Service
|
Example in plain text:
network:
floatingIPs:
- <svc-name>
Note
It is not currently possible to deploy floating IPs using the Terraform module. See the Cloud UI or CLI options. Alternatively, you may extend the Virtual Server Terraform module yourself.
Last modified 1mo ago