Create block storage to be attached to an instance.
Block storage can be created with empty storage containing no data, or by snapshots of existing block storage.
To create empty block storage, select Empty block storage, with no source for Block Storage Source. Empty block storage must be attached to instance, with partitions divided, and formatted, before use. Refer to Block Storage Overview > Use Empty Block Storage on how to use block storage. The availability zone where empty block storage is to be located must have an instance to which block storage is to be attached. For volume type, choose either HDD or SSD, based on the required I/O performance.
You can also create block storage from snapshots. In this case, the size of block storage must be the same as or larger than that of a snapshot. To set a larger size, the customer must manually adjust partitions of existing block storage or add more partitions so as to make use of increased space.
To create block storage with snapshots, the availability zone of block storage will be fixed to the zone where the snapshot is stored. A block storage cannot be created in any different availability zone.
Check the following before deleting block storage:
Once deleted, block storage cannot be restored.
Attach block storage to an instance. You can attach block storage while the instance is running. Block storage can only be attached to an instance in the same availability zone. When creating block storage, make sure that you create the block storage in the same availability zone as the instance to attach to.
If you attach empty block storage, it must be partitioned and formatted in the instance before use. A formatted block storage must be mounted before use. For block storage created with snapshots, you must mount it manually within the instance to use it.
[Note] Depending on the operating system, mounting may be automatically applied, requiring no further mounting process.
Detach unnecessary block storage from an instance. Note, however, that default disk cannot be detached.
You can detach block storage even while the instance is running. However, you must first unmount the block storage from the instance and detach the block storage in the console. Detaching while the block storage is mounted causes the following issues:
# umount <mount point>
Make the disk Offline in Disk Management and then detach it.
Create a read-only copy of the block storage. Although block storage snapshots can be created while the block storage is attached to an instance, it is recommended to detach it from the instance and create block storage snapshots to ensure data consistency and reliability.
You can use block storage by replicating it to another region. Although block storage can be replicated while being attached to an instance, it is recommended that you stop the instance or detach the block storage from the instance and proceed with replication to ensure data consistency and reliability.
After requesting replication, you can check the replication status and whether the replication is successful or not in Replication Status.
[Note] The replication function is a one-time operation, and changes to the original block storage after the replication are not reflected.
[Caution] To proceed with replication, at least 100KB of free space in block storage is required.
Select a region to replicate to other than the region you are currently using.
Select the type of block storage to use in the region to which to replicate. You can select a type that is different from the block storage type being used in the current region.
Select the availability zone to use in the region to which to replicate. You can select an availability zone that is different from the availability zone being used in the current region.
The instance might boot with block storage additionally attached to the instance mounted on
/. This usually happens when you attach block storage created with the instance's OS image to another instance additionally.
Linux determines which disk to mount on
etc/fstab at boot time. For the OS images used by NHN Cloud, the disk to mount is determined based on the file system UUID. If block storage with the same file system UUID value is attached, unintended block storage may be mounted on
# cat /etc/fstab ... UUID=6cd50e51-cfc6-40b9-9ec5-f32fa2e4ff02 / xfs defaults 0 0
You can check the file system UUID of block storage with the
# blkid /dev/vda1: UUID="6cd50e51-cfc6-40b9-9ec5-f32fa2e4ff02" TYPE="xfs" /dev/vdb1: UUID="6cd50e51-cfc6-40b9-9ec5-f32fa2e4ff02" TYPE="xfs"
As shown above, if the file system UUID of the additionally attached block storage is the same, the additionally attached block storage might be mounted on
/ depending on how the Linux distribution works.
Use the following steps to solve the problem by making the file system UUIDs of the two block storage different.
After stopping the instance, detach the block storage that is causing the problem (that is, the one that was mounted on
Start the instance.
When booting is complete, attach the block storage that is causing the problem.
Use the command below to change the file system UUID of the block storage that is causing the problem. Execute the command below according to the type of block storage causing the problem. The type of block storage can be found with the
If the file system of the block storage causing the problem is ext4:
# tune2fs -U random /dev/vdb1 tune2fs 1.42.9 (28-Dec-2013) Setting the UUID on this filesystem could take some time. Proceed anyway (or wait 5 seconds to proceed) ? (y,N) y
If the file system of the block storage causing the problem is xfs:
# xfs_admin -U generate /dev/vdb1 Clearing log and setting UUID writing all SBs new UUID = 0037c590-0545-4736-bcdc-d052681eb5f5
Verify that the file system UUID has been changed.
# blkid /dev/vda1: UUID="6cd50e51-cfc6-40b9-9ec5-f32fa2e4ff02" TYPE="xfs" /dev/vdb1: UUID="0037c590-0545-4736-bcdc-d052681eb5f5" TYPE="xfs"