Skip to main content

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.

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.

Deployment method: CoreWeave Cloud UI​

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

View this snippet on our GitHub for further context.

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:

OptionDescription
AlwaysA Virtual Server will always be present. If the Virtual Server crashed, a new one will be spawned.
RerunOnFailureDefault. 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).
ManualThe presence of a VirtualMachineInstance or lack thereof is controlled exclusively by the start/stop/restart VirtualMachine subresource endpoints.
HaltedNo 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.

Deployment method: Cloud UI​

To change the default RunStrategy for a Virtual Server, define the strategy to use in the spec.runStrategy field using the YAML editor.

Field nameField typeDescription
runStrategyVirtualMachineRunStrategyDefines RunStrategy parameter. Default value is RerunOnFailure.

Example in plain text:

  runStrategy: Always

useVirtioTransitional​

Enables virtio-transitional to support compatibility with older guest Operating Systems. The default value is false.

Deployment method: Cloud UI​

Open the YAML editor to configure virtio-transitional.

Field nameField type
useVirtioTransitionalBoolean

Example in plain text:

useVirtioTransitional: false

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."

Deployment method: CoreWeave Cloud UI​

Open the YAML editor to configure terminationGracePeriodSeconds.

Field nameField typeDefault values
terminationGracePeriodSecondsInteger60 - Linux systems
300 - Windows systems

Example in plain text:

terminationGracePeriodSeconds: 60

initializeRunning​

Determines whether or not the Virtual Server should be started as soon as it is created and initialized.

Deployment method: CoreWeave Cloud UI​

Open the YAML editor to configure initializeRunning.

Field nameField type
initializeRunningBoolean

Example in plain text:

terminationGracePeriodSeconds: 60

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.

Deployment method: CoreWeave Cloud UI​

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 nameField typeDescription
network.floatingIPsListA list of Service references to be added as floating IPs
network.floatingIPs[ ].serviceNameStringThe name of the Service

Example in plain text:

  network:
    floatingIPs:
    - <svc-name>