A virtual disk (vDisk) represents a VM’s view of its storage devices, which could include any type of physical disk (such as a file-backed disk image, an ISO image file, a physical hard drive, a CD/DVD device, or a block device) associated to a VM. The vDisk objects are discovered, along with their associated VM, when a Discover VM Images job is run on a repository.
The vDisk is modeled as a Grid object, located as a subordinate to the VM Grid object in the Explorer tree of the Orchestration Console. In the Explorer Tree, a vDisk is given the form vmname_vdisk<n> where <n> represents the numerical order in which this vDisk was discovered, with 1 appended to the name of the first vDisk discovered or created. For example, suse11_vdisk1 would be the name of the first disk discovered for a VM with the Grid ID suse11. Each additional vDisk is incremented by one, so the second vDisk in this example would be named suse11_vdisk2.
This section includes the following information:
This section includes the following information:
You might want to manually create a vDisk in the following scenarios:
When you want to create a “blank” disk image file for the VM. In this scenario, the disk image does not actually reside on the local file system, but a disk image of the specified size (measured in MB) should be created at the location specified for use by the VM. This is essentially a blank file, until it is used by the VM.
When the Orchestration Server might not have discovered the vDisk objects correctly, such as omitting a disk that should exist. You need to manually correct the incorrect discovery.
A VM that already exists needs to have patches applied to it. The patches are delivered through an ISO file, which was not configured to be attached to the VM. This configuration lets the administrator configure the VM with access to the ISO disk image, then apply the patches, and then later delete the vDisk object, returning the VM to its original configuration.
You need to manually add the vDisk, select the
action in the Orchestration Console, then apply the patches to the running VM. Later, you shut down the VM, delete the vDisk object from the Orchestration Server, then select the action again.The scenario includes configuring the VM to use the existing ISO file (that is, creating the vDisk object, then selecting
), and then deconfiguring the VM to no longer use the ISO file (that is, deleting the vDisk object, then selecting ).In this scenario, only the vDisk object from the Orchestration Server is deleted, not the ISO file.
To create a virtual disk in the Orchestration Console, you can either right-click the VM where you want to create the vDisk, then select Step 4 below) or you can use the following procedure from the Orchestration Console menu:
(if you do this, you can skip toIn the Orchestration Console main menu, select
> to display the Create a New Virtual Disk dialog box.In the
drop-down list, select the name of the VM where you want to add a vDisk, then click .When you have created all of the vDisks you need, click
.Select a newly created vDisk object in the Explorer tree to view the Info/Groups page of the admin view.
On the Info/Groups page, configure the following settings:
Type: Specify the vDisk type as the VM host sees it.
Description: Describe the vDisk with any text that you choose
Healthy: Designates the health state of the vDisk. Do not configure.
Moveable: Specifies whether the disk image can be copied (relocated) with the VM when the VM is moved (relocated) to another repository. For more information, see “Moveable” later in this section.
Mode: Specifies the mode of the vDisk as made available and supported by the provisioning adapter:
r = read only
w = read/write
VM: Specifies the name of the VM that uses this vDisk.
Repository: The repository where this disk location path resides.This setting is important because the Orchestration Server uses it to find a suitable VM host for provisioning, building, or migration actions. The value of this setting can be , which informs the server to ignore this vDisk when locating a suitable VM host.
Physical Disk: The name of the pDisk that this vDisk is associated with.
Location: The path (location) to the disk image.
If you specify a location to a disk that already exists, the existing disk file is used and the VM configuration is modified (according to the value in vdisk.location fact) to use this existing disk.
If you specify a path to a disk that does not exist (that is, if the value in vdisk.location is invalid), the action fails and an empty disk image file of the specified size is created. An error in the action status or job log is created.
For a vDisk created for a Hyper-V VM, you need to provide the complete path of that vDisk file.
To form the path, you need to know the repository path where the VM currently resides, the vDisk name, which is the name you give it plus the .vhd extension. For example, the syntax would be
<value_of_the_repository.preferredpath_fact>\<your_vhd_filename>.vhd
NOTE:Make sure that the .vhd file you designate in this field doesn’t already exist in the path.
Size: The size (measured in MB) of the disk image. Do not configure.
Sparse Disk: Designates whether the vDisk file is a sparse file. Do not configure.
Actual Size: The actual sparse size (measured in MB) of the vDisk file. Do not configure.
Click the Save button in the toolbar to save the fact changes you made.
In the Explorer tree, right-click the VM object where you added the vDisk, then select
to apply the changes to the VM’s configuration.Sparse disk creation is supported by the Xen, vSphere, and KVM hypervisors. If you want to create your vDisk as a sparse file, you can use the procedure for Creating and Configuring a Virtual Disk (see Step 5 in particular).
You need to set the Sparse Disk fact to true, specify the amount of space (in MB) for the disk in the Size fact, and also specify the path to the repository where the sparse vDisk resides. Make sure that you perform the action to apply the vDisk changes to the VM’s configuration.
You might want to manually delete a vDisk in at least two scenarios:
When the Orchestration Server might not have discovered the vDisk objects correctly, such as adding a disk that should not exist. The administrator needs to manually correct the incorrect discovery.
A VM that already exists needs to have patches applied to it. The patches are delivered through an ISO file, which was not configured to be attached to the VM. This configuration lets the administrator configure the VM with access to the ISO disk image, then apply the patches, then later delete the vDisk object, returning the VM to its original configuration.
The administrator needs to manually add the vDisk, run the Save Config command from the Orchestration Console, then apply the patches to the running VM. Later, the administrator shuts down the VM, deletes the vDisk object from the server, then performs the
action again.The scenario includes configuring the VM to use the existing ISO file (that is, creating the vDisk object and selecting the
action), then deconfiguring the VM to no longer use the ISO file (that is, deleting the vDisk object, then selecting the action).In this scenario, only the vDisk object from the server is deleted, not the ISO file.
To delete a virtual disk, you can either right-click the vDisk object in the Explorer, then select Step 4, below), or you can use the following procedure from the Orchestration Console:
(if you do this, you can skip toIn the Orchestration Console, select
> > to display the Delete a Virtual Disk dialog box.In the
list, select the name of the vDisk (hold down the Ctrl key to select multiple objects), then click to move these objects to the list.When you have selected all of the vDisks you want to delete, click
to display the Delete dialog box.In the dialog box, select
to delete all of the vDisk objects in the list, select if you want to delete the files associated with the vDisks you have selected, click , then click .In the Explorer tree, right-click the VM object where you deleted the vDisk, then select
to apply the changes to the VM’s configuration.NOTE:The config.xen for the xen provisioning adapter), but it does not delete any vDisk files on the file system. In this case, manual deletion of the vDisk file is required.
action rewrites the configuration file for the VM (for example,To delete a VM and its backing files, use the
action.For a VM to be provisionable by other VM hosts, all of a VM’s vDisks must be visible in the same way that the VM’s default repository (resource.vm.repository) is visible to VM hosts. If a VM has multiple vDisks and each vDisk has a different associated repository, these repositories must also be visible from a potential VM host.
When you move a VM to a new repository (see the Move Disk Image action for each hypervisor at Section 18.0, The VMware vSphere Provisioning Adapter), all of that VM’s moveable vDisk images (see Moveable:) are moved with it to be co-located in the same repository. The Orchestration Server uses the aggregated size of each moveable vDisk to determine if the designated repository has enough space for all of the disk images. vDisks that are marked as not moveable stay in place and are not used in the calculation for the VM disk size.
The following illustration further explains this concept:
Figure 6-1 Example of Moving Virtual Disks with the VM
VM host 1, VM host 2, and VM host 3 all have their own local storage repositories.
VM host 1 has a vDisk located on it. It is designated as a moveable vDisk.
VM host 1 and VM host 2 are also connected to a shared NAS storage repository.
The local repository connected to VM host 1 has a vDisk located on it. It is designated as a moveable vDisk.
The shared NAS repository has a vDisk located on it. It is designated as a non-moveable vDisk.
NOTE:Shared repositories are not created on discovery. They must be manually created and the sharing (visibility) configured.
VM host 1 has a VM located on it.
VM host 3 cannot communicate with the NAS repository; its vmhost.repositories fact does not include the NAS repository in the array, so that repository is not visible to VM host 3.
If you want to move the VM from VM host 1 to another VM host, the server manifests the following behavior:
The vDisk sizes used by the VM (on local storage and shared storage) are aggregated and compared to free space available on the repositories.
The only vDisk that is allowed to move is the moveable disk. This disk would be copied to either the shared NAS repository or the local storage on VM host 2.
VM host 3 is not considered because it does not have access to the non-moveable disk on the NAS repository.