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

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.

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

runStrategy

VirtualMachineRunStrategy

Defines 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

useVirtioTransitional

Boolean

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

terminationGracePeriodSeconds

Integer

60 - 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

initializeRunning

Boolean

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.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>
PreviousCloud-initNextRemote Access and Control

Last updated