Region, Hardware and Firmware

Select the data center region, hardware, and firmware for a Virtual Server

Region

Virtual Servers may be deployed across any of data center regions. CoreWeave's data center regions are broken up into three geographical buckets - US East, Central and West. Each provides redundant 200Gbps+ public Internet connectivity from Tier 1 global carriers, and are connected to each other using 400Gbps+ of dark fiber transport to allow for easy, free transfers of data within CoreWeave Cloud.

Note

It is generally advised to select the data center region closest to your location.

Cloud UI

Deployment method: CoreWeave Cloud UI

From the CoreWeave Cloud UI Virtual Server deployment menu, click the Region expandable, then select the region in which to host the Virtual Server by clicking on it.

CLI

Deployment method: Kubernetes CLI

Selecting a region for your Virtual Server is simple using the Kubernetes manifest file.

The data center region you'd like to use is configured by setting its label under the region selector in the spec section of the manifest.

Data center region configuration options

Variable name	Variable type	Description	Default value
region	String	The label of the data center in which you'd like to deploy the Virtual Server.	3

In the example below, the Chicago (ORD1) data center is chosen under spec.region.

Example

---
apiVersion: virtualservers.coreweave.com/v1alpha1
kind: VirtualServer
metadata:
  name: vs-ubuntu2004-block-pvc
spec:
  region: ORD1

Terraform

Deployment method: Terraform

The data center region for the Virtual Server can be defined in the vs_region variable in your variables.tf file.

Data center region configuration options

Variable name	Variable type	Description	Default value
vs_region	String	The data center region in which to deploy the Virtual Server.	ORD1 (Chicago)

Terraform example:

Example

variable "vs_region" {
  description = "Region default from vs_regions map"
  default     = "ORD1"
}

Hardware

CoreWeave Cloud offers several high-performance NVIDIA GPUs and CPUs for Virtual Servers. The amount of memory with which a Virtual Server runs can also be specified.

Cloud UI

Deployment method: CoreWeave Cloud UI

From the CoreWeave Cloud UI Virtual Server deployment menu, click the Hardware expandable, then select the hardware kind (GPU or CPU) and the hardware itself. Clicking the GPU tab will display all available GPU options, and clicking the CPU tab will do the same for CPU types.

Note

For more information on hardware, see Node Types.

The GPU Count, Core Count, and Memory amount (in Gi) are chosen using the sliders at the bottom of the section.

Each hardware selector also displays a meter registering the availability of that hardware type per region.

Resource definition (YAML only)

In the CRD's YAML manifest, the .spec.resources.definition field is used as a way to describe the chosen resources. The default value of this field is a - this is just a placeholder, which can be changed to any string.

Example in plain text:

Example

  spec:
    region: LAS1
    resources:
      cpu:
        count: 4
        type: amd-epyc-milan
      definition: a
      memory: 12Gi

CLI

Deployment method: Kubernetes CLI

Using the Kubernetes CLI deployment method, hardware options are configured under the resources block in the Virtual Server manifest (e.g., virtual-server.yaml).

In this method, hardware designations are defined as a kind of resource, just like CPU type, CPU core count, GPU count, and memory.

Hardware and resource configuration options

Each of the following fields will be configured underneath the resources block in the YAML manifest.

Field name	Type	Description
resources	Array	The top-level field. Defines the resources and devices allocated to the Virtual Server.
resources.definition	String	The resource definition. Defaults to a.
resources.cpu	Array	All CPU configuration fields.
resources.cpu.type	String	The type of CPU to allocate.
resources.cpu.count	Int	The number of CPU cores to allocate.
resources.gpu	Array	All GPU configuration fields.
resources.gpu.type	String	The type of GPU to allocate.
resources.gpu.count	Int	The number of GPU units to allocate.
resources.memory	String	The amount of memory to allocate.

Example

Example

  resources:
    gpu:
      type: Quadro_RTX_4000
      count: 1
    cpu:
      count: 4
    memory: 16Gi

Terraform

Deployment method: Terraform

The Virtual Server's hardware and resource options are configured as variables passed into the Virtual Server Terraform module.

Hardware and resource configuration options

The following table describes the variables usable for Virtual Server configuration, as well as whether or not the module defines any default values for them.

Variable name	Variable type	Description	Default value
vs_cpu_count	Integer	Number of CPUs requested. ⚠️ This option cannot be used if vs_gpu_enable is set to true.	3
vs_gpu_enable	Boolean	Enable GPU (or not) for this Virtual Server.	true
vs_gpu	String	The name of the GPU model to be used for the Virtual Server. ⚠️ Required if vs_gpu_enable is set to true.	Quadro_RTX_4000
vs_gpu_count	Integer	Number of GPUs requested for the Virtual Server. ⚠️ Required if vs_gpu_enable is set to true.	1
vs_memory	String	Memory specified for the Virtual Server, in Gi (eg. 16Gi).	16Gi

Example

Example

variable "vs_memory" {
  description = "Virtual Server RAM"
  default     = "16Gi"
}

variable "vs_root_storage" {
  description = "Virtual Server root device storage (i.e 80Gi)"
  default     = "80Gi"
}

variable "vs_os_type" {
  default = "linux"
}

variable "vs_image" {
  description = "OS image"
  default     = "ubuntu2004-docker-master-20210601-ord1"
}

variable "vs_gpu" {
  description = "GPU"
  default     = "Quadro_RTX_4000"
}

variable "vs_gpu_enable" {
  default = true
}

variable "vs_cpu_count" {
  default = 3
}

variable "vs_gpu_count" {
  default = 1
}

Firmware

Firmware identification information for Virtual Servers is set by the Virtual Machine Instance (VMI). The firmware's UUID (MAC address) is set by the BIOS, and its system-serial number is set by the VMI's SMBIOS.

The firmware's UUID defaults a randomly-generated alphanumeric string. Both numbers are static across Virtual Server restarts.

It is optional to set these; if not set, they will have randomly-generated defaults.

Note

You can read more about virtual hardware firmware configuration in the Kubevirt documentation, or see how its exposure is implemented in CoreWeave by viewing our API reference.

Cloud UI

Deployment method: CoreWeave Cloud UI

In the Cloud UI, firmware options must be set using the YAML editor. Firmware options are not currently exposed through the YAML manifest by default, so they must be added to the key-value map in the manifest.

Example in plain text:

Example

firmware:
  uuid: 5d307ca9-b3ef-428c-8861-06e72d69f223
  serial: e4686d2c-6e8d-4335-b8fd-81bee22f4815

CLI

Deployment method: Kubernetes CLI

Firmware options for Virtual Servers are configured under the firmware stanza.

Field name	Field type	Description
firmware	Array	Top-level field for firmware definitions
firmware.uuid	String	The UUID of the firmware to be deployed
firmware.serial	String	The system-serial-number in SMBIOS of the firmware to be deployed

Example in plain text:

Example

  firmware:
    uuid: 906820cf-53b7-45d6-9a6e-1c389cb81016
    serial: 5cc667ec-0bba-4011-af9e-05659c64d061

Terraform

Deployment method: Terraform

Note

It is not currently natively possible to configure firmware when using Terraform as the deployment method. This setting may be configured in conjunction with use of the Cloud UI or the Kubernetes CLI. Alternatively, you may extend the Virtual Server Terraform module yourself.