Contents
This design document explains the issue that emerges from the usage of the detach operation to file-based disks and provides a simple solution to it. Note that this design document applies only to disks of template file and sharedfile, but not gluster. However, for brevity reasons these templates will go under the umbrella term file-based.
When creating a file-based disk, Ganeti stores it inside a specific directory, called file_storage_dir. Inside this directory, there is a folder for each file-based instance and inside each folder are the files for the instance’s disks (e.g. <file_storage_dir>/<instance_name>/<disk_name>). This way of storing disks seems simple enough, but the detach operation does not work well with it. The reason is that if a disk is detached from an instance and attached to another one, the file will remain to the folder of the original instance.
This means that if we try to destroy an instance with detached disks, Ganeti will correctly complain that the instance folder still has disk data. In more high-level terms, we need to find a way to resolve the issue of disk ownership at the filesystem level for file-based instances.
The change we propose is simple. Once a disk is detached from an instance, it will be moved out of the instance’s folder. The new location will be the file_storage_dir, i.e. the disk will reside on the same level as the instance folders. In order to maintain a consistent configuration, the logical_id of the disk will be updated to point to the new path.
Similarly, on the attach operation, the file name and logical id will change and the disk will be moved under the new instance’s directory.
Before detaching a disk from an instance, we do the following:
Transform the current path to the new one.
<file_storage_dir>/<instance_name>/<disk_name> –> <file_storage_dir>/<disk_name>
Use the rpc call call_blockdev_rename to move the disk to the new path.
Store the new logical_id to the configuration.
Before attaching a disk to an instance, we do the following: