CoreWeave
Search…
⌃K

Additional Features

Learn more about other configurations available for Virtual Servers.
Discussed below are the additional features Virtual Servers offer for finer-grained control and niche use cases.

Ephemeral root disks

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
Deployment method: CoreWeave Cloud UI
Note
It is not currently possible to deploy ephemeral root disks using the Cloud UI. See the CLI option.
Deployment method: Kubernetes CLI
When configuring an ephemeral root storage disk, the source image is cloned into a ReadOnlyMany type volume, as shown in the example below.
Additional Resources
View this snippet on our GitHub for further context.
---
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 ... [email protected]
network:
public: false
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.

RunStrategy

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:
  • Always: A Virtual Server will always be present. If the Virtual Server crashed, a new one will be spawned.
  • RerunOnFailure: 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.
Additional Resources See the Kubevirt documentation for more information.
Cloud UI
CLI
Terraform
Deployment method: Cloud UI
Note
It is not currently possible to configure RunStrategy from the Cloud UI. See the CLI option.
Deployment method: Kubernetes CLI
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
Defines RunStrategy parameter. Default value is RerunOnFailure.
Example
runStrategy: Always
Deployment method: Terraform
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.

useVirtioTransitional

Enables virtio-transitional to support compatibility with older guest Operating Systems. The default value is false.
Cloud UI
CLI
Terraform
Deployment method: Cloud UI
Note It is not currently possible to configure useVirtioTransitional through the Cloud UI. This feature may be configured in conjunction with the Kubernetes CLI.
Deployment method: Kubernetes CLI Enabling virtio-transitional is done by configuring the Kubernetes manifest.
Field name
Field type
useVirtioTransitional
Boolean
Example
useVirtioTransitional: false
Deployment method: 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.

terminationGracePeriodSeconds

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
Note It is not currently possible to configure useVirtioTransitional through the Cloud UI. This feature may be configured in conjunction with the Kubernetes CLI.
Deployment method: Kubernetes CLI
Configuring the termination grace period is done through the Kubernetes manifest.
Field name
Field type
Default value
terminationGracePeriodSeconds
Integer
60 - Linux systems 300 - Windows systems
Example
terminationGracePeriodSeconds: 60
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.

initializeRunning

Determines whether or not the Virtual Server should be started as soon as it is created and initialized.
Cloud UI
CLI
Terraform
Deployment method: Cloud UI
Note It is not currently possible to configure initializeRunning through the Cloud UI. This feature may be configured in conjunction with the Kubernetes CLI.
Deployment method: Kubernetes CLI
Configuring initializeRunning is done through the Kubernetes manifest.
Field name
Field type
initializeRunning
Boolean
Example
terminationGracePeriodSeconds: 60
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

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
Deployment method: CoreWeave Cloud UI To configure Floating IPs on the Cloud UI, navigate to the YAML tab and find the floatingIPs field. This field is an array of load balancer Service names. If configured, the Virtual Server will be assigned floating IPs from the load balancer IP of each service.
The floatingIPs option as exposed through the YAML tab on the Cloud UI
Deployment method: Kubernetes CLI
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
network:
floatingIPs:
- <svc-name>
Deployment method: Terraform
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.