A method for creating and extending logical volumes on a virtual Linux guest by automatically calculating the size needed based on free storage in a volume group and available host storage.
Publication Date: 2016-Sep-06
The IP.com Prior Art Database
In a virtualized environment the function of adding storage to a virtual guest is comprised of several steps which involve provisioning the storage to the guest from the underlying hypervisor, and then configuring the storage on the guest. In some situations however, there is no need for the first step, if sufficient stroage is already allocated to the guest and is simply unutilized. In other cases, in order to provide the guest with the requested amount of strorage, a combination of configration changes has to be done in order to fulfil the request. This article desribes a method for adding an arbitrary amount of storage to the guest, taking into account pre-allocated storage residing on LVM volume groups. While this article focuses on virtual environments under IBM's z/VM hypervisor, the concepts can be applied to any virtual environment.
Page 01 of 4
A method for creating and extending logical volumes on a virtual Linux guest by automatically calculating the size needed based on free storage in a volume group and available host storage .
LVM (Logical Volume Manager) is a facility in Linux which facilitates management of storage at the Linux OS level. using three basic concepts, LVM allows the administrator to easily configure storage to serve file systems to the Linux OS. These three concepts are PVs (Physical Volumes), VGs (Volume Groups) and LVs (Logical Volumes). PVs are an LVM representation of the actual physical disk. VGs are an aggregate of PVs. LVs are software-defined volumes whose storage is provided by the VGs. Therefore, LVs can span PVs. LVM provides many methods of managing these objects which will not be included in this article, and are mostly irrelevant to the main purpose of this article.
In a virtualized environment, the PVs are defined on virtual disks provided to the guest by the underlying hypervisor. In the case of z/VM for example, these can be dedicated DASD volumes, minidisks or SCSI LUNs accessed by dedicated FCP devices. These PVs are then assigned to VGs, out of which LVs are carved and serve as storage containers for file systems. These file systems are then mounted on various mount points and hold the data for the virtual server.
Fig 1 - Storage hierarchy in a virtualized environment under z/VM
This means there is no simple way to add an arbitrary amount of storage to a guest. That storage has to be first available from the Host (the underlying hypervisor) or predefined (as part of a VG) in the guest for the linux admin to use it. Also when requesting a new storage to be added
Page 02 of 4
from the host, at least in the case of z/VM storage is specified in one of 3 forms (FBA blocks, DASD Cyls or the size of LUN (megabytes) those should be converted from the requested amount of storage and the admin needs to make sure the conversions are correct and match the new allocations requested by the user (Especially when also using pre-existing free space in a Volume Group)
The suggested method targets two main obstacles, currently not addressed by prior art:
The ability to automatically gather information from two separate sources (available storage on the volume group, and available storage on the host) and use that information to calculate the delta that has to be added to the guest from the host storage.
The ability to translate and match that delta from a variety of host storage types to guest storage in terms...