When you want to back up a virtual machine of a virtualization platform, a common approach is to first add the configuration information of the virtual machine itself to the backup, and then the contents of the virtual machine’s disks. When restoring a virtual machine backup, this same information will be needed to create an instance of the virtual machine on the virtualization platform and subsequently populate the disks with data from the newly created virtual machine backup. Today we will see how to do this on the VMware platform.
Disclamer
Astra Group has its own solutions in the Virtualization/Private Cloud portfolio. We are currently working on a complete backup solution for both private and public clouds. However, the process of business migration from foreign solutions is not yet complete and will continue in the future. In its working practice, RuBackup team faced the task of creating a backup of the VMvare platform. In this article we will describe the case that was implemented on the client side.
In case of working with VMware virtualization platform, we in RuBackup SRK follow the same pattern, but taking into account the specifics of this platform. If we get information about the virtual machine configuration via REST API from the vCenter host, then a special proprietary library is used to work with the virtual machine disk contentsvixDiskLibis a VMware library written in the C programming language. In this article we will take a closer look at working with this library, namely:
Getting information about the virtual machine disk
Backup the virtual machine disk to a backup copy
Restore a virtual machine disk from a backup to a newly created virtual machine
In the described case study we take version 7 of the libraryvixDiskLibas well as vCenter and esxi of a similar version. As an example of working with the libraryvixDiskLibthe creators of the library offer a file with the codevixDiskLibSample.cppcontaining an example of how to use the libraryvixDiskLib. This file is located in thevmware-vix-disklib-distrib/doc/samples/diskLibof the library archive file. In this article, we will modify this example so that it can make local backups of virtual machine disks, and restore those backups to pre-created VM disks on the VMware virtualization platform.
Getting started with the example program
To run the vixDiskLib library sample program in this article, you will need a Linux operating system and access to a vCenter host to run the VMware virtualization platform.
Let’s unzip the archive with the libraryvixDiskLibLet’s build and run the sample program. To build this program, first make sure that your Linux OS has the gcc compiler and make utility packages installed. You can build our program by going to the directoryvmware-vix-disklib-distrib/doc/samples/diskLiband running the commandmake.
To run the example program under consideration, you must specify the following command line parameters:
host: the address of the host where vCenter resides. Assume that this host is located atvcenter.corp.ru.Make sure that this address is correctly handled by the DNS domain name service. This is usually done by adding an entry to the file/etc/hostsor to your DNS server configuration.
user: the name of the vCenter user. Assume that this isrubackup
password: password for vCenter userrubackupand let’s assume that it’sP@ssword!
thump: the https checksum of the vCenter host certificate. It is essentially a set of two-digit hexadecimal numbers separated by a colon. For a vCenter host, this checksum can be obtained using the openssl utility with the console command:openssl s_client -connect vcenter.corp.ru:443 /dev/null | openssl x509 -fingerprint -noout -in /dev/stdin. You can also get this information from your web browser by going to vcenter.corp.ru. In the case of Mozilla Firefox, right-click on the security icon in the address bar, then select \”Secure Connection\”, then \”More Details\”. In the window that opens up, you need to click on the “View Certificate” button, then find the “Fingerprints” field and next to the line “SHA-1” will be the value you are looking for.
For the same information for other web browsers, please refer to the documentation of the respective web browser.
vm: the unique virtual machine identifier for vCenter.vixDiskLibdoes not allow you to simply access a virtual hard disk, you must specify the identifier of the virtual machine to which the virtual hard disk you are interested in is connected. There are several ways to find out this identifier, in particular, using a web browser you can do it by going to the vCenter website. Click on the virtual machine you are interested in and look at the address bar. It will look something like this: \”https://vcenter.corp.ru/ui/app/vm;nav=v/urn:vmomi:VirtualMachine:vm-1111:1ba1ac11-3d4a-425b-8b9f-9f76b501191a/summary\”. What’s highlightedvm-1111,and will be the unique identifier of the virtual machine. This identifier is called a MoRef (Management Object Reference). It starts with the stringvm, followed by a dash to specify the unique virtual machine identifier for this vCenter. For the example program, the full value of this parameter will look like this: \”moref=vm-1111\”.
The next parameter will be the name of the command to be executed in this call to the sample program. We will look at commands later.
The last parameter is the full path to the virtual hard disk of the VM on the remote datastore, for which we want to perform the operation specified in step 6. The full path consists of the datastore name and the location of the virtual hard disk file on this datastore. The easiest way to get this path is to use a web browser by going to the vCenter host. On the virtual machine you are interested in, click the \”Edit\” link, expand the drop-down list with the virtual hard disk you are interested in and copy the value of the \”Disk File\” field.
In this case, the full disk path looks like this: \”[datastore] test_vm/test_vm.vmdk\”, where \”[datastore]\” is the name of the datastore, \”test_vm\” is the name of the folder in the datastore that contains the virtual machine, \”test_vm.vmdk\” is the name of the disk. Since this parameter contains a space, it must be enclosed in single or double quotes, or escaped according to the rules of the shell used.
Let’s run the example program, but before that, for simplicity’s sake, let’s set an environment variable in which we define all unchangeable parameters:
In the future, we will use this variable when running our example program. If you use any special characters in your username or password, remember to escape them according to the rules of your shell. To run the sample program, we will navigate to the directory with the commandcd ~/vmware-vix-disklib-distrib/doc/samples/diskLib
Since the sample program uses shared librariesvixDiskLib, set the paths to find them using the environment variableLD_LIBRRAY_PATH:
Please note that all runs of the example program will be done for a powered off virtual machine, because vCenter does not allow different entities to open the same virtual hard disk at the same time. In our test example we backup a disk from a powered off virtual machine, but in real operation of the CDS before starting the backup procedure a snapshot is created from a running virtual machine and the CDS adds data from the snapshot to the backup without interrupting the virtual machine.
Next, let’s run the sample program with the info command, which requests basic information from the virtual hard disk.
$ ./vix-disklib-sample $VCENTER_PARAMS -vm moref=1111 -info \''[datastore] test_vm/test_vm.vmdk\''
Disk[0] \"[datastore] test_vm/test_vm.vmdk\" is opened using transport mode \"nbd\".
capacity = 419430400 sectors
logical sector size = 512 bytes
physical sector size = 512 bytes
number of links = 1
adapter type = LsiLogic SCSI
BIOS geometry = 0/0/0
physical geometry = 26108/255/63
Transport modes supported by vixDiskLib: file:nbdssl:nbd
Disk[0] is closed.
If this command is executed successfully and outputs the result, it means that your sample program is built and configured correctly. Further we will cite only the part of the output from the example that is of direct interest to us. We will omit the rest because the volume is very large.
The most important line in this conclusion for us is.capacity = 419430400 sectorswhich says that the disk size is 419430400 sectors of the virtual hard disk. Each such sector is 512 bytes in size.
Virtual hard disk backup
Our task is to backup the virtual hard disk of a virtual machine. That’s why the commanddumpexample program, which allows you to output the contents of sectors of a virtual hard disk specified by the parametersstartиcount.
Let’s output sectors 10 and 11 of the disk using the dump command:
If we have the ability to output the contents of a disk from an arbitrary location, we can thus make a function that will copy the contents of a remote virtual hard disk to a local file. Let’s add a new command to the sample programlocaldumpwhich will make a copy of the disk from the remote datastore to a local file.
In this code, when passing our sample program the commandlocaldumpthe handler of this command will be called – the functionDoLocalDump. Inside this function, we create a virtual hard disk object to get the size of the virtual hard disk and its handle. Then in the loop the contents of the virtual hard disk are copied to the temporary buffer by calling the functionVixDiskLib_Readand then saved sequentially to a local file.
How can we check if our virtual disk backup matches the original virtual hard disk?
The easiest way is to calculate the md5 sum of the copy disk and the original disk, because in this case we are copying the whole disk as is. For a local copy of the disk obtained by the example program, you can do it by running the commandms5sumvm_disk_local_dump. For the original disk, you need to ssh to the VMware host hypervisor over ssh, then navigate to the folder corresponding to the datastore of the disk of interest, and run the command as well:md5sum /vmfs/volumes/14171d1d-d161610a-1f18-141715181f14/test_vm/test_vm-flat.vmdk. In this command./vmfs/volumes/14171d1d-d161610a-1f18-141715181f14is the path to the root folder of the datastore,test_vm– virtual machine folder,test_vm-flat.vmdk.– virtual hard disk file with data. The actual values will depend on your VMware virtualization environment configuration.
It is important to note that this method will only work if the virtual machine containing this virtual hard disk does not contain any snapshots.
This backup procedure will be relevant for so-called fat virtual hard disks, that is, those that allocate all of their disk space at the time of their creation, or disks that are filled to 100% of their nominal size. But VMware also allows you to create disks that allocate disk space as needed, that is, as the virtual machine runs. This approach is somewhat slower to run the virtual machine than the previous approach, but it allows for a more economical use of free disk space on the datastore. To find out whether all disk space of a virtual hard disk is allocated at the moment of its backup or not, you can use the commandgetallocatedblocksfrom the example program. For a disk that has already allocated all of its disk space, the output of the command will look like this:
$ ./vix-disklib-sample $VCENTER_PARAMS -vm moref=1111 -getallocatedblocks -chunksize 128 \'[datastore] test_vm/test_vm.vmdk\'
Disk[0] \"[datastore] test_vm/test_vm.vmdk\" is opened using transport mode \"nbd\".
Number of blocks: 1
Offset Length
0x0000000000000000 0x000000400000
allocated size (4194304) / capacity (4194304) : 100%
Disk[0] is closed.
Note the valueallocated size 100%. Such a disk can be backed up using the method described above. But if the output of the command looks like the following, it will be ineffective to use the disk backup method described above:
$ ./vix-disklib-sample $VCENTER_PARAMS -vm moref=1111 -getallocatedblocks -chunksize 128 \'[datastore] test_vm/test_vm.vmdk\'
Disk[0] \"[datastore] test_vm/test_vm.vmdk\" is opened using transport mode \"nbd\".
Number of blocks: 303
Offset Length
0x0000000000000000 0x0000000000001800
0x00000000100800 0x00000001E800
0x0000000018D41000 0x0000000000006800
0x00000018D48000 0x0000000000006000
0x0000000018FFF000 0x0000000000001000
allocated size (102545408) / capacity (419430400) : 24%
Disk[0] is closed.
Notice the percentage value in the line starting withallocated size. A value of 24% tells us that not all of the virtual hard disk space is allocated. In turn, this means that we can put only the allocated parts into the backup, and this can reduce the backup time and reduce the backup size compared to the first backup method. The backup method in such a case can be roughly described as:
Get a map of allocated blocks of the virtual hard disk of the virtual machine, save it to a backup copy.
Save each block from the allocated blocks map again to a backup.
But this way of backing up a virtual hard disk still has some disadvantages: the procedure of obtaining the list of allocated blocks can be long. This is especially true for virtual hard disks whose virtual machine has many snapshots. It can also be time-consuming in cases where snapshots have been periodically created and deleted, but no virtual hard disk consolidation operation has been performed. To maintain optimal virtual machine performance, keep only those virtual machine snapshots that are actually needed and perform virtual hard disk consolidation of virtual machines on a regular basis.
To do this, in the vCenter web interface, invoke the context menu for the virtual machine you are interested in, then select \”Snapshots\”→\”Consolidate\”. The same menu items apply to the esxi hypervisor web interface. For virtual hard disks that have 95% or more of the total allocated blocks in relation to the total virtual hard disk, backing up by the first method often takes less time than backing up only the allocated blocks of the virtual hard disk.
Let’s add a new commandlocaldumpallocatedwhich will again make a copy of the remote virtual hard disk locally, but keeping only the allocated blocks of the virtual hard disk.
#define LOCAL_DUMP_FILE_MAP \"vm_disk_local_dump_map\"
typedef std::vector VixDiskAllocatedBlocks;
// Function to get vector of allocated blocks
static VixDiskAllocatedBlocks DoGetAllocatedBlocksVec();
// Function of saving the vector of allocated blocks to a local file
static void DoLocalDumpBlockFile(const std::string& filename, const VixDiskAllocatedBlocks& allocated_blocks);
static void
DoLocalDumpOneBlock(std::ofstream& output_file, VixDiskLibHandle disk_handle, const VixDiskLibBlock& block) {
const unsigned num_sectors = 1000;
std::vector buf(VIXDISKLIB_SECTOR_SIZE * num_sectors);
for (VixDiskLibSectorType i = block.offset; i block.offset + block.length) {
read_sectors = block.offset + block.length - i;
}
VixError vixError = VixDiskLib_Read(disk_handle,
i,
read_sectors, buf.data());
CHECK_AND_THROW(vixError);
output_file.write((char*)&buf[0], read_sectors * VIXDISKLIB_SECTOR_SIZE);
}
}
static void
DoLocalDumpAllocated(void) {
const VixDiskAllocatedBlocks allocated_blocks = DoGetAllocatedBlocksVec();
if(!allocated_blocks.empty()) {
std::ofstream output_file(LOCAL_DUMP_FILE, std::ios::out | std::ios::binary);
if(output_file) {
VixDisk disk(appGlobals.connection, appGlobals.diskPaths[0].c_str(), appGlobals.openFlags);
DoLocalDumpBlockFile(LOCAL_DUMP_FILE_MAP, allocated_blocks);
for(unsigned i = 0; i < allocated_blocks.size(); ++i) {
DoLocalDumpOneBlock(output_file, disk.Handle(), allocated_blocks[i]);
}
}
else {
std::cerr<<\"Error open file:\"<<LOCAL_DUMP_FILE<<endl;
}
}
else {
std::cout<<\"No allocated blocks, nothing to dump\"<<<std::endl;
}
}
In this code, when passing the following command to the sample programlocaldumpallocatedwe’ll call its handler, the functionDoLocalDumpAllocated. Inside this function, we first obtain the vector of allocated blocks of the virtual hard disk by calling the functionDoGetAllocatedBlocksVecwhich is a copy of the original functionDoGetAllocatedBlocks– of the getallocatedblocks command handler. Then the vector of allocated blocks of the virtual hard disk is saved to a local file by calling the functionDoLocalDumpBlockFile. Then sequentially each allocated block is saved to the local file via function callDoLocalDumpOneBlock.
Recovery.
Now that the virtual hard disk has been backed up, let’s restore it.
Recovering a virtual hard drive byvixDiskLibassumes that we are opening a pre-created remote virtual hard disk through thevixDiskLiband write the contents of the backup to this open remote virtual hard disk. Since we already have two types of virtual hard disk backups – a saved entire virtual hard disk and only saved allocated areas of the virtual hard disk – there should be two procedures for restoring virtual hard disks, depending on the type of backup.
For simplicity, we will assume that if a file with a map of allocated virtual hard disk blocks exists in the backup, then only these blocks need to be restored. If the file with the map of allocated blocks of the virtual hard disk does not exist in the backup, we will restore the entire virtual hard disk.
Next, for the sake of brevity, we will consider restoring only a virtual hard disk that has allocated blocks in the backup. Let’s add a new command to the sample programuploadallocateddiskand its handler:
// Function for loading a vector of allocated blocks from a local file
static VixDiskAllocatedBlocks DoLoadBlockFile(const std::string& filename);
static void
DoUploadOneBlock(std::ifstream& input_file, VixDiskLibHandle disk_handle, const VixDiskLibBlock& block) {
const unsigned num_sectors = 1000;
std::vector buf(VIXDISKLIB_SECTOR_SIZE * num_sectors);
for (VixDiskLibSectorType i = block.offset; i block.offset + block.length) {
write_sectors = block.offset + block.length - i;
}
if(write_sectors) {
input_file.read((char*)&buf[0], write_sectors * VIXDISKLIB_SECTOR_SIZE);
VixError vixError = VixDiskLib_Write(disk_handle, i, write_sectors, buf.data());
CHECK_AND_THROW(vixError);
}
}
}
static void DoUploadAllocatedlDisk() {
const VixDiskAllocatedBlocks allocated_blocks = DoLoadBlockFile(LOCAL_DUMP_FILE_MAP);
VixDisk disk_to_restore(appGlobals.connection, appGlobals.diskPaths[0].c_str(),
appGlobals.openFlags);
std::ifstream input_file(LOCAL_DUMP_FILE, std::ios::in | std::ios::binary);
if(input_file.is_open()) {
for(unsigned i = 0; i < allocated_blocks.size(); ++i) {
DoUploadOneBlock(input_file, disk_to_restore.Handle(), allocated_blocks[i]);
}
}
else {
std::cerr<<\"Unable to open file:\"<<LOCAL_DUMP_FILE<<endl;
}
}
In this code, when passing our sample program the commanduploadallocateddiskits handler will be called – the functionDoUploadAllocatedlDisk. Inside this function, we first get the vector of allocated blocks of the virtual hard from the locally saved file by calling the functionDoLoadBlockFile. Next, each allocated block is passed sequentially to the functionDoUploadOneBlockwhich reads its contents from the local file into a temporary buffer and then writes it to the remote virtual hard disk by calling the functionVixDiskLib_Write.
Thin disk recovery
There is one flaw in our recovery procedure: if the virtual machine originally had a thin virtual hard disk, then when restoring by the methods above, the virtual machine gets a thick unallocated disk. This is often not what we need.
So what can we do to get a thin virtual hard disk or any other type of disk available to write data there from a backup when restoring? First, we need to find out if the virtual machine we are backing up is a thin disk. The easiest way to get this answer is to use a web browser by going to the vCenter website. On the virtual machine you are interested in, click the \"Edit\" link, expand the drop-down list with the disk you are interested in and look at the Type field. If the disk is thin, the value of this field will be Thin Provision.
But you can also do this using the libraryvixDiskLibusing the sample program and its commandmeta. The output of this command will look like this:
./vix-disklib-sample $VCENTER_PARAMS -vm moref=1111 -meta \'[datastore] test_vm/test_vm.vmdk\'
Disk[0] \"[datastore] test_vm/test_vm.vmdk\" is opened using transport mode \"nbd\".
adapterType = lsilogic
geometry.cylinders = 512
geometry.heads = 128
geometry.sectors = 32
longContentID = 918149eeb8f01751f1ed01f1fffffffe
thinProvisioned = 1
uuid = 60 00 C1 94 bb 39 c1 03-28 e1 ea 9c b1 43 c0 ec
virtualHWVersion = 14
Disk[0] is closed.
Here we need to pay attention to the presence of the fieldthinProvisioned. If the virtual hard disk was created as a thin disk, this field will be present and its value will be 1. If the disk was created as a thick disk, this field will be absent.
vixDiskLiboffers the following method for creating thin disks on a remote datastore:
Create a thick disk on the local file system.
Clone the thick disk created in step 1 to the remote datastore as a thin virtual hard disk.
Upload data from the backup to the virtual hard disk cloned in step 2.
But why can’t you eliminate step 2 in this sequence and create the thin disk locally right away? The point is that thin disks are the essence of datastores with a file systemVMFS.vixDiskLibcannot create a thin virtual hard disk on local filesystems as ext4 does. Important note for those using NFS-based datastores: this type of datastore does not support thin disks.
Create a virtual hard disk locally in the filevirtdisk.vmdkcommand./vix-disklib-sample -create -cap 16384 virtdisk.vmdk. The disk size is specified by the -cap parameter in megabytes. In this case, the formal disk size will be 16 GB. But in fact such a file will occupy less space on the file system, which will give us an opportunity to save space on the local file system. Such files are called discharged files. The disk size passed to the keycapfile size must be exactly the same as that of the virtual hard disk that was previously backed up. You can also optionally set the virtual adapter type for the virtual hard disk with the parameter-adapter(ide or scsi, default is scsi).
The next step is to clone the local virtual hard disk to the remote datastore.
By default, the sample program uses the following disk type when cloningVIXDISKLIB_DISK_DISK_MONOLITHIC_SPARSE. For our purpose, however, in the functionDoCloneof the example program needs to replace this value with the variablecreateParams.diskTypeсVIXDISKLIB_DISK_MONOLITHIC_SPARSE.onVIXDISKLIB_DISK_DISK_VMFS_THIN,to clone a previously locally created disk as a thin disk.
Next, we need to directly clone this disk to a remote datastore using the example program under consideration. This can only be done by connecting directly by the sample program to the esxi hypervisor host that hosts the virtual machine we are interested in. As in the case of connecting to vCenter, let’s define a separate environment variable with the parameters for connecting to the esxi hypervisor host:
Note that the parametervmhere corresponds to the virtual machine identifier in the identity scheme of this esxi hypervisor, not vCenter. In fact, it’s not even a MoRef, since there is no prefix at the beginning of the identifiervm. This value can be obtained from the browser address bar in the same way that the MoRef value for a virtual machine on vCenter was obtained for the esxi host.
Let’s run the command to clone the local virtual hard disk as a thin disk. A data size equal to the size of the originally created local virtual hard disk will be transferred:
Here you can also specify the virtual adapter type of the virtual hard disk to be cloned.
The remote virtual hard disk passed as an argument will now be of type thin disk.
To verify this, open the virtual hard disk properties of the virtual machine for which the cloning operation was performed in the vCenter web interface. By default, the original virtual hard disk type will be displayed there. Disconnect this virtual hard disk without removing it from the datastore from the virtual machine. Save the changes, reopen the Edit Virtual Machine window and reconnect the same virtual hard disk to the same VM. You will see that the type of the virtual hard disk has changed to thin and the disk has the size that was set when creating the local virtual hard disk with the commandcreateof the sample program. After that, such a virtual hard disk can be restored from a backup in a way that only allocated blocks of the virtual hard disk are restored from the backup.
Conclusion
This article has taken a sequential look at the initial approaches to backing up and restoring virtual hard disks on the VmWare platform. Starting with obtaining basic information about virtual hard disks parameters, we continued by creating a procedure for backing up a remote virtual hard disk to a local file system. But the backup itself is meaningless without a subsequent restorer, so we looked at restoring a thin virtual hard disk to a remote datastore, taking into account the limitations for this operation.
FOLLOW
SUBSCRIBE FOR A COOKIE! ON USIIC.CO
Accomplishments
- Raised $20,000,000 To Plant 20,000,000 Trees
- Given millions to charity
- Donated over 100 cars lol
- Gave away a private island
- Given away over 100 ps4s lol
- Gave away 1 million dollars in one video
- Counted to 100k
- Read the Dictionary
- Watched Dance Till You're Dead For 10 Hours
- Read Bee Movie Script
- Read Longest English Word
- Watched Paint Dry
- Ubering Across America
- Watched It's Every Day Bro For 10 Hours
- Ran a marathon in the world's largest shoes
- Adopted every dog in a shelter
You get the point haha
*Do not email me asking for money, I give away money because it makes me happy :)
How to choose a reliable smartphone Choosing a reliable smartphone for work and play involves considering several key factors that can affect your productivity and entertainment experience. Here are some tips to help you choose the right smartphone for your needs: By considering these factors, you can choose a smartphone that is reliable and well-suited […]
Falcon IPTV has rapidly emerged as a popular choice for streaming television content over the internet. Offering an array of channels and features, it has gained attention from those seeking an alternative to traditional cable and satellite TV. Features of Falcon IPTV Falcon IPTV boasts a range of features that contribute to its popularity among users […]
Gaming consoles continue to evolve, offering better performance, stunning graphics, and new immersive experiences. With technological advancements and innovation, 2024 promises to deliver some of the best gaming consoles on the market. Here are the Top 10 Gaming Consoles of 2024, complete with specifications, advantages, manufacturer details, and prices. 1. PlayStation 5 Pro Advantages: 2. […]
![]("https://habrastorage.org/r/w1560/getpro/habr/upload_files/7aa/419/b07/7aa419b07e4da24a199bb758aa91b1a2.png")
![]("https://habrastorage.org/r/w1560/getpro/habr/upload_files/942/44f/c54/94244fc544851c8265a5279ebc01527c.png")
