Skip to main content

Linux Images

CoreWeave offers a variety of optimized Linux base images, with out-of-the-box support for several popular distributions including Ubuntu Linux, CentOS, and Rocky Linux. These images are distributed as PVCs in the vd-images namespace.

To locate a desired image, use our metadata labels. For example, to get a list of all the latest public Linux images:

Example
# Get the latest CoreWeave Linux master images

$
kubectl get pvc -n vd-images -l images.coreweave.cloud/latest=true,images.coreweave.cloud/private=false,images.coreweave.cloud/family=linux

It's a best practice to choose an image in the same region as the Virtual Server deployment.

Tip

Most "Generic Cloud" distribution images are also drop-in compatible with CoreWeave Cloud. See Importing a QCOW2 image for more information.

Flavors​

Our Linux images are available in three different flavors:

  • Docker-only
  • Docker with NVIDIA drivers
  • Docker with NVIDIA drivers and Teradici Graphics Agent

Docker-only​

All Linux images are pre-installed with the Docker Engine. Docker-only images are not intended to be used with a GPU, and therefore do not have a desktop environment or NVIDIA drivers.

To locate these images, select docker for the images.coreweave.cloud/features metadata label.

Example
# Fetch Linux images with Docker only

$
kubectl get pvc -n vd-images -l images.coreweave.cloud/latest=true,images.coreweave.cloud/private=false,images.coreweave.cloud/family=linux,images.coreweave.cloud/features=docker

Docker with NVIDIA​

These images include the Docker Engine, the NVIDIA Container Toolkit, and NVIDIA GPU drivers.

The NVIDIA driver version is periodically changed in new image releases, pending validation and dependency matches. These images contain NVIDIA drivers and are intended to be used with a GPU but no desktop environment is installed.

To locate these images, select nvidia_docker for the images.coreweave.cloud/features metadata label.

Example
# Fetch Linux images with Docker and NVIDIA drivers

$
kubectl get pvc -n vd-images -l images.coreweave.cloud/latest=true,images.coreweave.cloud/private=false,images.coreweave.cloud/family=linux,images.coreweave.cloud/features=nvidia_docker

Docker with NVIDIA and Teradici​

These images include the Docker Engine, the NVIDIA Container Toolkit, NVIDIA GPU drivers, and the Teradici Graphics Agent.

Out of the box, the graphics agent points to a CoreWeave Licensing Server, where Teradici subscription licenses are billed at an hourly rate. These are intended for use as a Virtual Workstation and come pre-installed with the GNOME Desktop Environment. Linux Virtual Servers deployed with Teradici can be accessed with clients for Windows, macOS, and Linux, and more.

To locate these images, select nvidia_teradici_docker for the images.coreweave.cloud/features metadata label.

Example
# Fetch Linux images with Docker, NVIDIA and Teradici

$
kubectl get pvc -n vd-images -l images.coreweave.cloud/latest=true,images.coreweave.cloud/private=false,images.coreweave.cloud/family=linux,images.coreweave.cloud/features=nvidia_teradici_docker

cloud-init​

All Linux images provided by CoreWeave Cloud include cloud-init for instance instantiation.

Cloud-init provides a powerful way to provision an instance programmatically, or pass through generic metadata.

Tip

See more in Cloud-init.

cloud-init Modules​

cloud-init has various modules that process different directives from the provided metadata manifest.

Modules are processed based on the configuration file located in /etc/cloud/cloud.cfg. As default, the following modules are processed:

Example
# The modules that run in the 'init' stage

cloud_init_modules:

 - migrator

 - seed_random

 - bootcmd

 - write-files

 - [ growpart, always ]

 - [ resizefs, always ]

 - disk_setup

 - [ mounts, always ]

 - [ set_hostname, always ]

 - update_hostname

 - update_etc_hosts

 - ca-certs

 - rsyslog

 - users-groups

 - ssh



# The modules that run in the 'config' stage

cloud_config_modules:

# Emit the cloud config ready event

# this can be used by upstart jobs for 'start on cloud-config'.

 - emit_upstart

 - snap

 - ssh-import-id

 - keyboard

 - locale

 - set-passwords

 - grub-dpkg

 - apt-pipelining

 - apt-configure

 - ubuntu-advantage

 - ntp

 - timezone

 - disable-ec2-metadata

 - runcmd

 - byobu



# The modules that run in the 'final' stage

cloud_final_modules:

 - package-update-upgrade-install

 - fan

 - landscape

 - lxd

 - ubuntu-drivers

 - write-files-deferred

 - puppet

 - chef

 - mcollective

 - salt-minion

 - reset_rmc

 - refresh_rmc_and_interface

 - rightscale_userdata

 - scripts-vendor

 - scripts-per-once

 - scripts-per-boot

 - scripts-per-instance

 - [ scripts-user, always ]

 - ssh-authkey-fingerprints

 - keys-to-console

 - install-hotplug

 - phone-home

 - final-message

 - power-state-change
Note

For more information, see cloud-init's Module Reference.

Modules in cloud.cfg that do not have a frequency specified follow the default behavior outlined in the Module Reference. CoreWeave images configure select modules to process "always", vs "once-per-instance":

  • growpart
  • resizefs
  • mounts
  • set_hostname
  • scripts-user

This ensures, respectively:

  • Partitions are re-sized after disk expansion
  • File Systems are re-sized after disk expansion
  • New Shared File Systems and other mounts are auto added to fstab and mounted
  • hostname updates are respected
  • Userdata scripts are always processed

Virtual Server cloud-init abstractions​

Some properties in a Virtual Server Manifest map to cloud-init properties, and automatically populate those fields:

spec.users[]​

spec.users[] in a Virtual Server manifest populates cloud-init metadata for the users and groups module.

The resultant metadata generated looks like this:

Example
users:

- lock_passwd: false

  name:

  plain_text_passwd:

  shell: /bin/bash

  ssh_authorized_keys:

  - ""

  sudo: ALL=(ALL) NOPASSWD:ALL

storage.filesystems[]​

Adding File System mounts to a Virtual Server manifest populates cloud-init metadata for the mounts module.

The resultant metadata generated looks like this:

Example
mounts:

- - viofs-${name}

  - /mnt/${name}

  - virtiofs

  - rw,noatime,_netdev,nofail

  - "0"

  - "2"

metadata.name​

The name of a Virtual Server is used to set the hostname, using the cloud-init Update Hostname module.

The resultant metadata generated looks like this:

Example
hostname: ${name}

Additional cloud-init metadata​

Outside of the cloud-init abstractions provided in the Virtual Server spec, additional cloud-init metadata can be added to a manifest via spec.cloudInit[]. Metadata is passed as a multi-line string literal. As an example using the cloud-init Package Update module:

Example
cloudInit: |

  package_update: true

The additional cloud-init metadata will be merged with the abstracted fields from the Virtual Server spec. The resultant, full metadata generated looks like this:

Example
hostname:

ssh_pwauth: "True"

users:

- lock_passwd: false

  name:

  plain_text_passwd:

  shell: /bin/bash

  ssh_authorized_keys:

  - ""

  sudo: ALL=(ALL) NOPASSWD:ALL

package_update: true

Additional cloud-init metadata examples​

Using additional cloud-init metadata provides an easy, repeatable method of configuring an instance at initial deployment. Actions that one may perform manually when deploying a new instance can be automated via cloud-init.

Set system time zone​

Example
cloudInit: |

  set_timezone: america/los_angeles

Update package repositories and packages​

Example
cloudInit: |

  package_update: true

  package_upgrade: true
Note

This performs apt update && apt upgrade or yum upgrade on first boot.

Install packages​

Example
cloudInit: |

  packages:

    - cowsay

    - nyancat

    - [libpython2.7, 2.7.3-0ubuntu3.1]
Note

Prior to installing packages, the repository database is updated. If no package version is specified, the latest version is installed.

Run arbitrary commands​

Example
cloudInit: |

  runcmd:

    - [ ls, -l, / ]

    - ls -l /root

    - [ sh, -c, echo "=========hello world=========" ]
Note

Commands and arguments can be formatted in any of the ways listed above.

Inject and run a bash script​

Example
cloudInit: |

  write_files:

    - content: |

        #!/bin/bash

        echo "Hello World" > /tmp/test.txt

      owner: root:root

      path: /tmp/init.sh

      permissions: '0755'

  runcmd:

    - [ bash, /tmp/init.sh ]

Partition, format, and mount a new Block Volume​

Example
cloudInit: |

  # The disk_setup directive instructs Cloud-init to partition a disk.

  disk_setup:

    /dev/vdc:

      table_type: gpt

      layout: True

      overwrite: False

  # fs_setup describes the how the file systems are supposed to look.

  fs_setup:

    - label: None

      filesystem: ext4

      device: /dev/vdc

      partition: 'auto'

  # 'mounts' contains a list of lists; the inner list are entries for an /etc/fstab line

  mounts:

   - [ vdc, /mnt/block-pvc, auto, "defaults" ]

Full cloud-init Virtual Server manifest example​

The Virtual Server manifest below combines all the examples above:

Example
apiVersion: virtualservers.coreweave.com/v1alpha1

kind: VirtualServer

metadata:

  name: vs-ubuntu2204

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

      source:

        pvc:

          namespace: vd-images

          name: ubuntu2204-nvidia-515-43-04-1-teradici-docker-master-20220522-ord1

    additionalDisks:

      - name: vs-block-pvc

        spec:

          persistentVolumeClaim:

            claimName: vs-block-pvc

  users:

    - username:

      password:

  network:

    directAttachLoadBalancerIP: false

    public: true

  initializeRunning: true

  cloudInit: |

    set_timezone: america/los_angeles

    package_update: true

    package_upgrade: true

    packages:

      - git-all

      - unrar

      - openjdk-11-jdk

    write_files:

      - content: |

          #!/bin/bash

          KUBECTL_VERSION=v1.19.16

          curl -o /usr/local/bin/kubectl -sL https://dl.k8s.io/release/${KUBECTL_VERSION}/bin/linux/amd64/kubectl

          chmod +x /usr/local/bin/kubectl

        owner: root:root

        path: /tmp/install_kubectl.sh

        permissions: '0755'

      - content: |

          #!/bin/bash

          VIRTCTL_VERSION="v0.38.1"

          curl -o /usr/local/bin/virtctl -sL https://github.com/kubevirt/kubevirt/releases/download/${VIRTCTL_VERSION}/virtctl-${VIRTCTL_VERSION}-linux-amd64

          chmod +x /usr/local/bin/virtctl

        owner: root:root

        path: /tmp/install_virtctl.sh

        permissions: '0755'

    runcmd:

      - [ bash, /tmp/install_kubectl.sh ]

      - [ bash, /tmp/install_virtctl.sh ]

      - [ bash, -c, echo alias k=kubectl >> /etc/bash.bashrc ]

      - [ bash, -c, echo alias virt=virtctl >> /etc/bash.bashrc ]

    # The disk_setup directive instructs Cloud-init to partition a disk.

    disk_setup:

      /dev/vdc:

        table_type: gpt

        layout: True

        overwrite: False

    # fs_setup describes the how the file systems are supposed to look.

    fs_setup:

      - label: None

        filesystem: ext4

        device: /dev/vdc

        partition: 'auto'

    # 'mounts' contains a list of lists; the inner list are entries for an /etc/fstab line

    mounts:

     - [ vdc, /mnt/vs-block-pvc, auto, "defaults" ]

After creating the Virtual Server, output from the cloudInit directives can be found in /var/log/cloud-init-output.log:

Example
$
sudo cat /var/log/cloud-init-output.log



Cloud-init v. 22.1-14-g2e17a0d6-0ubuntu1~22.04.5 running 'init-local' at Sun, 05 Jun 2022 17:20:40 +0000. Up 6.62 seconds.

Cloud-init v. 22.1-14-g2e17a0d6-0ubuntu1~22.04.5 running 'init' at Sun, 05 Jun 2022 17:20:40 +0000. Up 7.32 seconds.
Last updated on