Modify the settings for a Google Cloud Hyperdisk volume

You can modify the properties of your Google Cloud Hyperdisk volumes to meet your workload's needs. For example, you can reduce or increase the provisioned IOPS or throughput to reduce costs or increase performance, respectively. You can specify how VMs access the data on Hyperdisk ML, Hyperdisk Balanced, and Hyperdisk Balanced High Availability volumes by setting the volume's access mode.

This page discusses how to modify the capacity, performance, and other settings of Hyperdisk volumes.

Before you begin

If you haven't already, then set up authentication. Authentication is the process by which your identity is verified for access to Google Cloud services and APIs. To run code or samples from a local development environment, you can authenticate to Compute Engine by selecting one of the following options:

Select the tab for how you plan to use the samples on this page:
Console

When you use the Google Cloud console to access Google Cloud services and APIs, you don't need to set up authentication.
gcloud
1. Install the Google Cloud CLI, then initialize it by running the following command:
  gcloud init
  Note: If you installed the gcloud CLI previously, make sure you have the latest version by running gcloud components update.
2. Set a default region and zone.
REST

To use the REST API samples on this page in a local development environment, you use the credentials you provide to the gcloud CLI.
For more information, see Authenticate for using REST in the Google Cloud authentication documentation.

Required roles and permissions

To get the permission that you need to modify a Hyperdisk, ask your administrator to grant you the following IAM roles on the project:

Compute Instance Admin (v1) (roles/compute.instanceAdmin.v1)
To connect to a VM that can run as a service account: Service Account User (v1) (roles/iam.serviceAccountUser)

For more information about granting roles, see Manage access to projects, folders, and organizations.

This predefined role contains the compute.disks.update permission, which is required to modify a Hyperdisk.

You might also be able to get this permission with custom roles or other predefined roles.

Overview of modifying Hyperdisk

You can change the access mode, size, and performance characteristics of Hyperdisk volumes.

Supported size and performance changes for Hyperdisk volumes

The following table summarizes the supported capacity and performance changes for each Hyperdisk type.

Hyperdisk type	Customizable throughput	Customizable IOPS	Shareable between VMs
Hyperdisk Balanced	Yes	Yes	Yes
Hyperdisk Balanced High Availability (Preview)	Yes	Yes	Yes
Hyperdisk Extreme	No	Yes	No
Hyperdisk ML	Yes	No	Yes, in read-only mode
Hyperdisk Throughput	Yes	No	No

The values you use when creating or modifying a Hyperdisk volume must fall within the range of maximum and minimum values described in Hyperdisk limits per disk.

If you're modifying the size of a Hyperdisk volume that's attached to a VM, then the new values can't exceed the Hyperdisk limits per VM.

The provisioned IOPS and throughput for a Hyperdisk volume must follow the rules outlined in About IOPS and throughput provisioning for Hyperdisk.

Capacity changes

You can resize a Hyperdisk volume only to increase its size. You can't reduce the capacity of a Hyperdisk volume. If you want to decrease the size of a Hyperdisk volume, you must create a smaller volume, migrate data from the original volume to the smaller volume, and delete the original volume.

You can resize a Hyperdisk volume even if it is attached to a running VM. However, if a Hyperdisk volume is in multi-writer mode, you must detach the volume from all VMs before you can resize it.

You can resize a Hyperdisk Throughput volume once every 6 hours. For all other Hyperdisk types, you can change the provisioned capacity once every 4 hours.

For the best results, complete the following steps when changing the capacity of a Hyperdisk volume:

Performance changes

You can change a volume's provisioned performance even if it is attached to a running VM.

After you change the provisioned IOPS or throughput, it can take up to 15 minutes for the changes to take effect. However, the following exceptions apply:

For Hyperdisk ML volumes, it can take up to 20 minutes for the changes to take effect.
For disks in multi-writer mode, performance changes can take up to 6 hours for the change to become effective if the disk was attached to multiple VMs when you made the change.

You can change the provisioned IOPS or throughput once every 4 hours for all Hyperdisk types except Hyperdisk ML. You can change the provisioned throughput of a Hyperdisk ML volume once every 6 hours.

Changing the provisioned IOPS or throughput for a Hyperdisk volume does not delete or modify disk data.

If you attempt to modify a Hyperdisk volume more than once within the specified limits, you will receive an error message like Cannot update provisioned throughput due to being rate limited.

Access mode changes

To attach a single Hyperdisk volume to multiple VMs, you must set the volume's access mode to read-only or multi-writer mode, depending on your use case.

Disable multi-read or multi-write access for a disk

To perform certain actions on a Hyperdisk volume, it must be in single-writer mode. For example, you can't create an image or a snapshot from a Hyperdisk volume in multi-writer mode. You must set its access mode to single-writer.

To disable multi-read or multi-write access, you must detach it from all VMs, then follow the instructions in Set the access mode.

Restrictions

To set a disk's access mode, it must be detached from all VMs.
For Hyperdisk ML volumes, you can't set the access mode back to read-write if you set it to read-only.
You can't set the access mode for Hyperdisk Throughput and Hyperdisk Extreme volumes.

Best practices

Since you must wait at least 4 hours between disk property changes, follow these best practices:

Avoid delays in modifying a disk by changing multiple properties at the same time. For example, if you plan to change both disk's size and provisioned IOPS within a short period, make both changes in a single request.
When choosing a new value for a disk's provisioned performance or size, remember that you can't make any further changes for 4 to 6 hours. For example, suppose you want to increase the size of a 500 GiB Hyperdisk Balanced volume to 1 TiB. Ensure that your workload won't require more than 1 TiB of disk space within the next 4 hours, since you can't increase the size again until 4 hours have passed.

Set the access mode of a Hyperdisk volume

To set a disk's access mode, it must be detached from all VMs.

You can make the following changes to a Hyperdisk volume's access mode:

For Hyperdisk Balanced and Hyperdisk Balanced High Availability (Preview) volumes, you can enable or disable multi-writer mode.
For Hyperdisk ML volumes, you can enable read-only mode.

You can't modify a Hyperdisk ML volume's access mode after you set it to read-only.

You can set the access mode with the Google Cloud console, the Google Cloud CLI, or REST.

Console

In the Google Cloud console, go to the Disks page.

Go to Disks
In the list of disks in your project, click the name of the Hyperdisk volume you want to modify.
On the disk details page, click Edit.
In the Access mode field, select the access mode that you want:
- To enable read-only mode, select Multiple VMs read only.
- To enable multi-writer mode, select Multiple VMs read-write
- (Default) To enable single-writer mode, select Single VM read-write.
To apply your changes, click Save.

gcloud

Run the disks update command and specify the access mode with the --access-mode flag.

gcloud compute disks update DISK_NAME  \
   --access-mode=DISK_ACCESS_MODE

Replace the following:

DISK_NAME: the name of the Hyperdisk volume that you are modifying.
DISK_ACCESS_MODE: how VMs can access the data on the disk. Supported values are:
- READ_ONLY_MANY, for read-only access from multiple VMs.
- READ_WRITE_MANY, for read-write access from multiple VMs.
- (Default) READ_WRITE_SINGLE, for read-write access from one VM.

REST

Construct a PATCH request to the compute.disks.update method. In the request body, set the access mode with the "accessMode" parameter.

PATCH https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/ZONE/disks/DISK_NAME/update
{
   "accessMode": "DISK_ACCESS_MODE"
}

Replace the following:

PROJECT_ID: your project ID.
ZONE: the zone where your Hyperdisk volume is located.
DISK_NAME: the name of the Hyperdisk volume to modify.
DISK_ACCESS_MODE: how VMs can access the data on the disk. Supported values are:
- READ_ONLY_MANY, for read-only access from multiple VMs.
- READ_WRITE_MANY, for read-write access from multiple VMs.
- READ_WRITE_SINGLE, for read-write access from one VM.

Change the size or provisioned performance of a Hyperdisk volume

You can increase the volume size and change the provisioned IOPS or throughput for a Hyperdisk volume with the following time limits:

Increase the disk size:
- For Hyperdisk Throughput: Once every 6 hours
- For all other Hyperdisk types: once every 4 hours
Modify the provisioned IOPS or throughput:
- For Hyperdisk ML: Once every 6 hours
- For all other Hyperdisk types: once every 4 hours

You can change the provisioned size and performance for a Hyperdisk volume with the Google Cloud console, gcloud CLI, or REST.

Console

In the Google Cloud console, go to the Disks page.

Go to Disks
In the list of disks in your project, click the name of the Hyperdisk volume for which you want to change the capacity or provisioned performance.
On the disk details page, click Edit.
1. In the Size field, enter the new size for your disk. The disk size must be in the range of supported values.
2. For Hyperdisk Extreme, Hyperdisk Balanced, and Hyperdisk Balanced High Availability: In the Provisioned IOPS field, enter the new IOPS value for your volume.
3. For Hyperdisk Throughput, Hyperdisk ML, Hyperdisk Balanced, and Hyperdisk Balanced High Availability: In the Provisioned throughput field, enter the new throughput value for your volume.
Click Save to apply your changes to the disk.

gcloud

Use the disks update command and specify the --size, --provisioned-iops, or --provisioned-throughput flags.

To change the size of a Hyperdisk Balanced High Availability volume, include the --region flag.

gcloud compute disks update DISK_NAME  \
    --size=DISK_SIZE  \
    [--region=REGION]  \
    --provisioned-iops=IOPS_LIMIT  \
    --provisioned-throughput=THROUGHPUT_LIMIT

Replace the following:

DISK_NAME: the name of the Hyperdisk volume that you are modifying.
DISK_SIZE: Optional: The new size of the disk. The value must be a whole number followed by a size unit of GB for gibibyte, or TB for tebibyte. The disk size must be in the range of supported values.
REGION: Optional. The region where the Hyperdisk Balanced High Availability disk is located
IOPS_LIMIT: Optional: The IOPS configuration for Hyperdisk Extreme, Hyperdisk Balanced, and Hyperdisk Balanced High Availability volumes. The value must be in the range of supported values.
THROUGHPUT_LIMIT: Optional: The throughput configuration for the Hyperdisk Throughput, Hyperdisk ML, Hyperdisk Balanced, or Hyperdisk Balanced High Availability volume, specified as an integer that represents the throughput measured in MiB per second. The value must be in the range of supported values.

REST

Construct a PATCH request to the compute.disks.update method. In the request body, specify the sizeGb, provisionedIops or provisionedThroughput parameters.

PATCH https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/ZONE/disks/DISK_NAME
{
   "sizeGb": "DISK_SIZE,
   "provisionedIops": "IOPS_LIMIT",
   "provisionedThroughput": "THROUGHPUT_LIMIT"
}

To modify a Hyperdisk Balanced High Availability volume, construct a PATCH request to the compute.regionDisks.update method.

PATCH https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION/disks/DISK_NAME
{
   "sizeGb": "DISK_SIZE,
   "provisionedIops": "IOPS_LIMIT",
   "provisionedThroughput": "THROUGHPUT_LIMIT"
}

Replace the following:

PROJECT_ID: your project ID.
ZONE: the zone where your Hyperdisk volume is located.
REGION: For Hyperdisk Balanced High Availability disks, this is the region where the disk is located.
DISK_NAME: the name of the Hyperdisk volume to modify.
DISK_SIZE: Optional: The new size of the disk. The value must be a whole number followed by a size unit of GB for gibibyte, or TB for tebibyte. The disk size must be in the range of supported values.
IOPS_LIMIT: Optional: The IOPS configuration for the Hyperdisk Extreme, Hyperdisk Balanced, or Hyperdisk Balanced High Availability volume. The value must be in the range of supported values.
THROUGHPUT_LIMIT: Optional: The throughput configuration for the Hyperdisk Balanced, Hyperdisk ML, Hyperdisk Balanced, or Hyperdisk Balanced High Availability volume, specified as an integer that represents the throughput measured in MiB per second. The value must be in the range of supported values.

If you attempt to modify a Hyperdisk volume's size or performance more than once within the specified limits, you will receive an error message like Cannot update provisioned throughput due to being rate limited or Disk cannot be resized due to being rate limited.

Back up the Hyperdisk volume

Resizing a disk doesn't delete or modify disk data, but as a best practice, always backup your disk by creating a snapshot before you make any changes to the file system or partitions.

Resize the file system and partitions

After increasing the size of your Hyperdisk volume, you might need to resize its file system and partitions:

Boot disk: If you are using a custom Linux image or a custom Windows image, you must manually resize the root partition and file system. For VMs with public images, Compute Engine automatically resizes the root partition and file system after you increase the size of the boot disk and restart the VM.
Non-boot disk: After increasing the size of the disk, you must extend the file system on the disk to use the added space.

The following examples shows how to manually resize the root partition and file system of a boot disk, and how to manually resize the file system of a non-boot data disk with no partition table. This example assumes that the attached disks were previously formatted and mounted.

Linux VMs

In the Google Cloud console, go to the VM instances page.

Go to VM instances
Click the SSH button next to the instance that has the new disk attached. The browser opens a terminal connection to the instance.
Use the df and the lsblk commands to list the size of the file system and to find the device names for your disks.
```
$ sudo df -Th

Filesystem      Type      Size  Used Avail Use% Mounted on
udev            devtmpfs  3.9G     0  3.9G   0% /dev
/dev/nvme0n1p1  ext4      9.7G  2.0G  7.2G  22% /
/dev/nvme0n1p15 vfat      124M   12M  113M  10% /boot/efi
/dev/nvme0n2    ext4       98G   24K   98G   1% /mnt/disks/data
```
```
$ sudo lsblk

NAME    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
nvme0n1      259:0    0   20G  0 disk
├─nvme0n1p1  259:5    0  9.9G  0 part /
├─nvme0n1p14 259:6    0    3M  0 part
└─nvme0n1p15 259:7    0  124M  0 part /boot/efi
nvme0n2      259:4    0  100G  0 disk /mnt/disks/data
```
This example includes the following disks:
- Boot disk: The /dev/nvme0n1p1 partition is on a boot disk that has been resized to 20 GB. The partition table and the file system provide only 9.9 GB to the operating system.
- Non-boot data disk: The /dev/nvme0n2 non-boot data disk has no partition table, but the file system on that disk provides 100 GB to the operating system. The mount directory for this disk is /mnt/disks/data.
Make note of the Type column in the df command output, which indicates if your disk uses an ext4 or xfs file system.
Verify the partition type:
```
sudo parted -l
```
The first time you run this command after resizing a disk, you might see a message similar to the following:
```
Warning: Not all of the space available to /dev/nvme0n1 appears to be
used, you can fix the GPT to use all of the space (an extra 20971520
blocks) or continue with the current setting?
Fix/Ignore?
```
If you enter Fix, the OS will automatically repartition the disk to make the additional space available to the OS. Skip ahead to the last step if you don't have any additional disks to modify.
If you choose not to use the automatic fix option, or it isn't available, view the information for the disk you want to repartition:
```
sudo parted -l /dev/DEVICE_NAME
```
Look for field: Partition Table, if the value is msdos then the disk has an MBR partition type. This means the maximum size of such disk would be 2 TB.
For a boot disk, resize the root partition and file system on the disk. This example assumes the VM image does not support automatic root partitioning and file system resizing.
1. Resize the root partition by using parted. For example, the following commands expand partition 1 of the device to the maximum possible size:
  1. Open parted on the device:
```
sudo parted /dev/DEVICE_NAME
```
  2. At the prompt, enter:
```
(parted) resizepart
```
  3. At the Partition number? prompt, enter:
```
1
```
  4. At the Warning: Partition /dev/DEVICE_NAMEp1 is being used. Are you sure you want to continue? prompt, enter:
```
Yes
```
  5. At the End? prompt, enter
```
100%
```
  6. At the (parted) prompt, enter:
```
(parted) quit
```
2. View the new partition table using parted -l.
```
sudo parted -l /dev/DEVICE_NAME

Model: nvme_card-pd (nvme)
Disk /dev/DEVICE_NAME: 21.5GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:

Number  Start   End     Size    File system  Name  Flags
14      1049kB  4194kB  3146kB                     bios_grub
15      4194kB  134MB   130MB   fat16              boot, esp
1       134MB   21.5GB  21.3GB  ext4
```
3. Extend the file system:
  - If you are using ext4, use the resize2fs command:
```
sudo resize2fs /dev/DEVICE_NAME
```
  - If you are using xfs, use the xfs_growfs command:
```
sudo xfs_growfs -d /
```
  - If you are using btrfs, use the btrfs command:
```
sudo btrfs filesystem resize max /
```
For a non-boot data disk, resize the file system on the disk.
- If you are using ext4, use the resize2fs command to extend the file system:
```
sudo resize2fs /dev/DATA_DEVICE_NAME
```
  Replace DATA_DEVICE_NAME with the device name for the data disk. In this example, the device name is /dev/nvme0n2.
- If you are using xfs, use the xfs_growfs command to extend the file system:
```
sudo xfs_growfs MOUNT_DIR
```
- If you are using btrfs, use the btrfs command to extend the file system:
```
sudo btrfs filesystem resize max MOUNT_DIR
```
  Replace MOUNT_DIR with the mount point of the device. You can find the mount point listed in the MOUNTPOINT column in the output of the lsblk command.

Use the df command to verify that the file system is extended. For example:

df -h /dev/DATA_DEVICE_NAME

Filesystem       Size  Used  Avail    Use%     Mounted on
/dev/DATA_DEVICE_NAME   118G  70M   118G     1%     MOUNT_DIR

Windows VMs

Use the Windows Disk Management utility to resize partitions on a Windows instance.

In the Google Cloud console, go to the VM instances page.

Go to VM instances
Next to the instance that has the resized disk, click the RDP button. The browser opens an RDP connection to the instance.
Right-click the Windows Start button and select Disk Management to open the Disk Management tool.
Show the disks partition type by running in Powershell:
```
Get-Disk
```
under Partition Style column, if the value is MBR then the disk has an MBR partition type. This means the maximum size of such a disk would be 2 TB.
Refresh the Disk Management tool so that it recognizes the additional space on your zonal persistent disk. At the top of the Disk Management window, click Action and select Refresh.
On the disk that you resized, right-click the formatted partition and select Extend Volume.
Follow the instructions in the Extend Volume Wizard to extend your existing partition to include the extra disk space. If the existing partition is formatted in NTFS, the maximum partition size is limited by its cluster size settings.
After you complete the wizard and the volume finishes formatting, check the Status column on the list of attached disks to ensure that the new disk has a Healthy status.

You don't need to restart your VM after you complete this process. You can now use the added disk space to store data.

What's next

Learn more about Hyperdisk.
Learn how to analyze the current IOPS level for a Hyperdisk volume.