Emailgency logo
Emergency
mail access
Baculasystems
Multi-platform

Backup VMware ESX(i) using ghettoVCB

You can backup and monitor your VMware hardware at the same time using esxmon module. The module detects status changes and send emails.

Did you ever try the new FTP upload feature?

Optimize your VMware backups, take a look to this article to know how fast are NFS, FTP and SSH.

Try new bazzarvcb beta at Magiksys

Try new bazzarvcb beta at Magiksys

Try new bazzarvcb beta at Magiksys

ghettoVCB.sh is a popular and free solution to backup virtual machines hosted on ESX(i) 3.5/4.x/5.x servers. The installation and configuration of a ghettoVCB backup is not easy, moreover the ESXi environment don't provide any reliable tools to send any email report.

MKSBackup front-end tries to improve ghettoVCB.sh usability, by running the script from a friendly Windows or Linux host and by sending an email report. The backup can be scheduled using the Windows task scheduler or the Linux crontab.

A very nice Spanish tutorial.

How it works   

You don't need to install anything on your ESX(i) server, just be sure SSH is enable.
Install MKSBackup on your Linux or Windows host, put the ghettoVCB.sh script and all configuration files in one local directory, and configure one section in your mksbackup.ini file like this one.

< don't forget the DEFAULT section and your mail configuration >
[VMWARE_JOB_NAME]
program=ghettovcb
host=192.168.1.11
login=root
password=secret
local=C:\Magik\vmware
remote_temp=/tmp
global_conf=ghettoVCB.conf
vm_list=vm01 vm02 "the lastvm"

MKSBackup uploads all files found in local directory into the remote_temp directory on your VMware server. Text files are converted to the UNIX format during the upload. Then MKSBackup starts the backup of VM in vm_list, running ghettoVCB.sh from the remote remote_temp directory. When done and if destination as been defined, MKSBackup can copy or move, backup files back to the local host using the scp utility or upload them to any FTP server. destination is optional ! MKSBackup will process all Virtual Machines in the vm_list and send you a single email report.
Backup can be scheduled in your crontab on Un*x or in your Task scheduler on Windows host.

FTP upload (using ftpput)

You will be very interested in comparing speed of different protocols and backup strategies, take a look to this article first !

Since version 0.9.30, MKSBackup handle FTP upload for the ghettoVCB.sh back-end. MKSBackup can even run its own built-in ftp server to allow local upload. FTP is a lot faster than SSH, 30Mo/s versus less than 10Mo/s for SSH on the same configuration !

Upload is done using build-in ftpput utility available in all VMware ESXi. ESX user can download ftpput from the download page. The same binary, include both ftpput and ftpget feature and can be renamed into ftpget for downloading.

As soon as ghettoVCB.sh has generated the first disk, or the first extent when using 2gbsparse, MKSBackup starts to uploads finished files while ghettoVCB.sh continue to backup other disks and VM. At the end of the last virtual machine, MKSBackup waits for the end of running uploads.

The FTP url and credentials are configured in the destination parameter. Look at this sample :

ftp_local=ftp://192.168.1.23/D/Backup/VMware

This line starts the built-in ftp server; the IP address of the host running MKSBackup must be specified. This line is only required when you expect to upload files on your localhost and don't want to install or setup a real FTP server. This server is waiting connection on IP 192.168.1.23 and will permit FTP clients to create directories and upload files in the D:\Backup\VMware directory, here on a Windows host.

destination=<backup=mon-thu>
            <copy=fri>E:\backup\vmware\${vm}-fri
            <copy=sat>ftp://username:password@192.168.1.101/backup/vmware/${vm}-${nweek}
            <copy=sun>ftp://localhost/${vm}

This configuration will do a normal backup during the week, following the configuration in your global_conf file. On Friday, the backup will be downloaded using SSH from your VMware server to your localhost in directory E:\backup\vmware\${vm}-fri . On Saturday, after the normal backup, files will be uploaded to a remote FTP server 192.168.1.101. On Sunday, files will be uploaded to the localhost itself, via the built-in FTP server started by the ftp_local option above. In this last case, files will be uploaded into directory D:\Backup\VMware\${vm}.
The general ftp url format is:

ftp://[username[:password]]@hostname_or_ip[:port][/directory]

Don't use hostname but prefer instead ip_addresse or don't forget to configure the DNS of your VMware and test the name resolution !

When using localhost, you don't need to specify username, password and port, they will be copied from the ftp_local field. If you don't specify these fields in ftp_local, they will be randomly initialized and secretly used by the VMware server to upoad the files. You don't need to setup these values except if you want to test the built-in server when the backup is running. You can force the use of port 21 if you like, just add :21 after your host IP or name. If you use hostname instead of IP address, your VMware server must be able to resolve the name.

Be careful to configure your local firewall to allow your built-in ftp server to accept connection.

If your host is a Windows system, setup the disk letter as the first directory of the directory part.

The ftpput command can only upload file and is unable to create directories on the remote FTP host. MKSBackup will try to created required directories, but if the backup host is unable to connect to the remote ftp server, you must create all these directories yourself !

Restore and FTP download

To help in the restore process, MKSBackup generate a download script and attach it to the mail report. Edit the script to modify the target directory and the ftp password and run it from your ESX(i) server. When downloaded, you still need to follow the standard ghettoVCB.sh restore process, using ghettoVCB-restore or doing it by hand.

If you have used the MKSBackup built-in ftp server, you can start MKSBackup as a ftp server standalone. For example if you have used

ftp_local=ftp://192.168.1.102/backup/vmbackup

in your .ini file, you can start it this way:

mksbackup ftp -P 12345 -r /backup/vmbackup -u ftp -p password -b 192.168.1.102

and be sure you have these lines a the begining of your download script:

HOST="192.168.1.102"
PORT=12345
USERNAME="ftp"
PASSWORD="password"

Use -h to get help. ftp keyword must be first argument of the command !

mksbackup ftp -h

FTP and SSH tricks

To speed up your backup, it is in your interest to start FTP/SSH up/download as soon as possible to have both, backup and up/download running at the same time. up/download starts as soon as something can be transfered. This can be a disk, or a 2G extend when using 2gbsparse backup format.

Then, backup small VM first or use 2gbsparse format for your first VM. Be careful 2gbsparse disk cannot be used by ESX(i) and must be converted into another format. (see ghettoVCB-restore and vmkfstools documentation).

2gbsparse format don't generate unix sparse files, unused blocks are left out of the files and the size correlates the real size of the data. Then 2gbsparse is the ideal format for archiving. Because FTP and SSH cannot handle sparse file, if size and transfer speed is your first priority, then 2gbsparse format should be your first choice.

Getting Started

For more information on how to install and start MKSBackup, visit the Overview page. You have the choice between multiple scenarios:

Backup all VM from a Windows host

When you have installed MKSBackup into C:\Magik\MKSBackup, you need to download and extract ghettoVCB.tar.gz in your local directory C:\Magik\vmware.

You have initialized your C:\Magik\mksbackup.ini like this:

[DEFAULT]
smtp_host=smtp.yourprovider.com
sender=backup.operator@server01.example.com
recipients=me@example.com  someone.else@domain.com

[VMWARE]
program=ghettovcb
host=<your vmware host ip>
login=root
password=<your vmware host password>
local=C:\Magik\vmware
global_conf=ghettoVCB.conf
vm_list=
vm_exclude=<list here the vm you want to exclude>

To backup all VM, you must let the vm_list empty. If you want to exclude VMs, list them in the vm_exclude option. If you don't want to exclude any VM, let the field empty or remove it.

Now we have to configure the ghettoVCB part by editing C:\Magik\vmware\ghettoVCB.conf. We want to backup our VMs to our NAS mounted in /vmfs/volumes/NAS01 and keep only 3 versions of the VM. Fore more detail about the ghettoVCB configuration, read the documentation page.

VM_BACKUP_VOLUME=/vmfs/volumes/NAS01/backup
DISK_BACKUP_FORMAT=thin
VM_BACKUP_ROTATION_COUNT=3
POWER_VM_DOWN_BEFORE_BACKUP=0
ENABLE_HARD_POWER_OFF=0
ITER_TO_WAIT_SHUTDOWN=3
POWER_DOWN_TIMEOUT=5
ENABLE_COMPRESSION=0
ADAPTER_FORMAT=buslogic
VM_SNAPSHOT_MEMORY=0
VM_SNAPSHOT_QUIESCE=0
ENABLE_NON_PERSISTENT_NFS=0
UNMOUNT_NFS=0
NFS_SERVER=172.30.0.195
NFS_MOUNT=/nfsshare
NFS_LOCAL_NAME=nfs_storage_backup
NFS_VM_BACKUP_DIR=mybackups
SNAPSHOT_TIMEOUT=15

We start the backup from a command prompt like this :

C:\Magik> C:\Magik\MKSBackup\mksbackup.exe -v -c C:\Magik\mksbackup.ini backup VMWARE

We used the -v switch to print debuging message on the console.

logging in mksbackup.log
07:37:02,172 INF start ['mksbackup.exe', '-v', '-c', 'C:\\Magik\\mksbackup.ini', 'backup', 'VMWARE']
07:37:04,942 INF cmd_line=cd "/tmp/vmware" ; ./"ghettoVCB.sh" -d debug -c "/tmp/vmware" -a -e "/tmp/vmware/exclude_vm" -g "ghettoVCB.conf"
07:37:04,943 INF No error in section: VMWARE
07:37:04,944 INF start command=backup
job=VMWARE archiver=ghettovcb
07:37:05,259 INF start: cd "/tmp/vmware" ; ./"ghettoVCB.sh" -d debug -c "/tmp/vmware" -a -e "/tmp/vmware/exclude_vm" -g "ghettoVCB.conf"
07:38:23,675 INF name=VMWARE
07:38:23,675 INF program=ghettovcb
07:38:23,676 INF version=0.8.4b
07:38:23,677 INF status=OK
07:38:23,678 INF hostname=f11asx.asxnet.loc
07:38:23,678 INF exit_code=0
07:38:23,679 INF start=Wed May 5 07:37:04 2010
07:38:23,680 INF end=Wed May 5 07:38:23 2010
07:38:23,680 INF type=backup
07:38:23,682 INF start_epoch=1273037824
07:38:23,682 INF end_epoch=1273037903
07:38:23,791 INF end command=backup job=VMWARE archiver=ghettovcb

You can increase verbosity using the -d switch to see the ghettoVCB.sh output. Check your email, you should have received one, including the log and most of the informations above.

To schedule this job read Schedule a daily backup.

Backup multiple VMs from a Linux host

When you have installed MKSBackup like in the Install section, you need to download and extract ghettoVCB.tar.gz in your local directory /etc/mksbackup/vmware.

You have initialized your /etc/mksbackup/mksbackup.ini like this:

[DEFAULT]
smtp_host=smtp.yourprovider.com
sender=backup.operator@server01.example.com
recipients=me@example.com  someone.else@domain.com

[VMWARE]
program=ghettovcb
host=<your vmware host ip>
login=root
password=<your vmware host password>
local=/etc/mksbackup/vmware
global_conf=ghettoVCB.conf
vm_list=cos5-tiny xp-test fedora11

This time we have setup a vm_list.
Now you have to configure the ghettoVCB part by editing /etc/mksbackup/vmware/ghettoVCB.conf. We want to backup our VMs to our NAS mounted in /vmfs/volumes/NAS01/backup and keep only 3 versions of the backups. Fore more details about the ghettoVCB configuration, read the documentation page.

VM_BACKUP_VOLUME=/vmfs/volumes/NAS01/backup
DISK_BACKUP_FORMAT=thin
VM_BACKUP_ROTATION_COUNT=3
POWER_VM_DOWN_BEFORE_BACKUP=0
ENABLE_HARD_POWER_OFF=0
ITER_TO_WAIT_SHUTDOWN=3
POWER_DOWN_TIMEOUT=5
ENABLE_COMPRESSION=0
ADAPTER_FORMAT=buslogic
VM_SNAPSHOT_MEMORY=0
VM_SNAPSHOT_QUIESCE=0
ENABLE_NON_PERSISTENT_NFS=0
UNMOUNT_NFS=0
NFS_SERVER=172.30.0.195
NFS_MOUNT=/nfsshare
NFS_LOCAL_NAME=nfs_storage_backup
NFS_VM_BACKUP_DIR=mybackups
SNAPSHOT_TIMEOUT=15

To backup the fedora11 VM when powered off, we create the file /etc/mksbackup/vmware/fedora11. If this file match the name of the VM, ghettoVCB will use the parameters in it. These ask to power the VM off before to backup it.

POWER_VM_DOWN_BEFORE_BACKUP=1
ENABLE_HARD_POWER_OFF=0
ITER_TO_WAIT_SHUTDOWN=4
POWER_DOWN_TIMEOUT=5

We start the backup from a command prompt like this :

/root # mksbackup -v -c /etc/mksbackup/mksbackup.ini backup VMWARE

An get this output :

logging in mksbackup.log
10:05:07,353 INF start ['mksbackup', '-v', '-c', '/etc/mksbackup/mksbackup.ini', 'backup', 'VMWARE']
10:05:08,342 INF cmd_line=cd "/tmp/vmware" ; ./"ghettoVCB.sh" -d debug -c "/tmp/vmware" -f "/tmp/vmware/current_vm" -g "ghettoVCB.conf"
10:05:08,344 INF scp_cmd=scp -P 22 -q root@192.168.23.9:%source% %destination%
10:05:08,345 INF No error in section: VMWARE
10:05:08,346 INF start command=backup job=VMWARE archiver=ghettovcb
10:05:08,872 INF start: cd "/tmp/vmware" ; ./"ghettoVCB.sh" -d debug -c "/tmp/vmware" -f "/tmp/vmware/current_vm" -g "ghettoVCB.conf"
10:06:25,135 INF program=ghettovcb
10:06:25,136 INF version=0.8.4b
10:06:25,137 INF status=OK
10:06:25,137 INF hostname=f11asx.asxnet.loc
10:06:25,138 INF exit_code=0
10:06:25,139 INF start=Wed May 5 10:05:08 2010
10:06:25,139 INF end=Wed May 5 10:06:24 2010
10:06:25,141 INF type=backup
10:06:25,142 INF target=
10:06:25,142 INF start_epoch=1273046708
10:06:25,143 INF end_epoch=1273046784
10:06:25,254 INF end command=backup job=VMWARE archiver=ghettovcb

Backup VMs and copy backups back to the host using SCP

MKSBackup can copy the backup files back to the host using SSH protocol. Unfortunately VMware don't allocate too much resources to this process and the copy is very slow ( usually bellow 3Mo/s, depending on hardware, platform and softwares). To use this feature, you have to add a destination parameter and select your SSH copy program. destination use the destination syntax.

This feature is not available when using non persistent NFS storage !

MKSBackup built-in SCP function is very very very slow !!! We still don't know why ! Anyway, MKSBackup has been tested with the Windows putty's pscp.exe command and the popular Un*x openssh scp provided with all GNU-Linux OSs.

Before to use this feature, you need to register your VMware server's host key in your SSH client cache This is done the first time you connect to your server.

Under Windows, use this command :

C:\Magik> "C:\Program Files\PuTTY\plink.exe" root@<your vmware host ip> ls /tmp
The server's host key is not cached in the registry. You
have no guarantee that the server is the computer you
think it is.
The server's rsa2 key fingerprint is:
ssh-rsa 2048 04:6c:89:31:ee:6c:44:44:ba:ce:93:e8:9f:62:bf:d2
If you trust this host, enter "y" to add the key to
PuTTY's cache and carry on connecting.
If you want to carry on connecting just once, without
adding the key to the cache, enter "n".
If you do not trust this host, press Return to abandon the
connection.
Store key in cache? (y/n) y
root@<your vmware host ip>'s password:********
sfcb      vmhsdaemon
ipkg.conf stage

Under Linux, use this command :

[root@eg01 tmp]# ssh root@<your vmware host ip> ls /tmp
The authenticity of host '192.168.23.106 (192.168.23.106)' can't be established.
RSA key fingerprint is 04:6c:89:31:ee:6c:44:44:ba:ce:93:e8:9f:62:bf:d2.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.23.106' (RSA) to the list of known hosts.
root@<your vmware host ip>'s password: ********
sfcb      vmhsdaemon
ipkg.conf stage

Here are the lines you have to add to your Windows mksbackup.ini to use ghettoVCB.sh as usual from Monday to Saterday and make a copy on Sunday. ${vm} will be replaced with the name of your virtual machines. Directory C:\Backup\VMware must exist !

destination=<backup=mon-sat>
            <copy=sun>C:\Backup\VMware\${vm}
scp_bin="C:\Program Files\PuTTY\pscp.exe"

Here are the lines you have to add to your mksbackup.ini on a Linux host to use ghettoVCB.sh as usual from Monday to Saterday and make an alternate copy between up yo two different targets. Directories /data1/backup/vmware and /data2/backup/vmware must exist !

destination=<backup=mon-sat>
            <copy=sun,wsun0/2>/data1/backup/vmware\${vm}
            <copy=sun,wsun1/2>/data2/backup/vmware\${vm}
scp_bin="/usr/bin/scp"

Unfortunately, for security reason, scp don't allow to specify the password on the command line ! Then you have to setup an authorized_keys key file to avoid the interactive password prompt.

On ESXi the .ssh directory is deleted at startup ! To make it persistent :

To schedule these job each days, look here

Job parameters

program (mandatory)

To use the ghettoVCB backend, program must be set to ghettovcb.

program=ghettovcb

host (mandatory)

This is the host ip or hostname of your ESX(i) server.

host=192.168.1.11

port (default is 22)

The port to connect to on the remote ESX(i) host.

port=22

login (default to /tmp)

This is the account used to login on your ESX(i) server through SSH.

login=root

password

This is the password of your login account on your ESX(i) server or the password of the identity_file when specified.

password=secret

identity_file

Selects a file from which the identity (private key) is read for public key authentication. MKSBackup detects automatically RSA and DSS (DSA) key. The key can be protected by a password specified in password.

identity_file=C:\Magik\id_dsa

local (mandatory)

This is where your ghettoVCB.sh and all your configuration files must be on your local host ! MKSBackup will copy this directory to remote_temp. Be careful, this is a copy not a sync, files will stay on the remote location, even if deleted on the source ! This directory should not contains sub-directories.

If files with the same name as the virtuals machines are found, they will be used by ghettovcb as specific configuration using the -c option.

MKSBackup accept ghettoVCB.sh using different case.

local=C:\Magik\vmware

remote_temp (mandatory)

This is where all files in local will be uploaded on your ESX(i) server. This directory must exist before to start the backup.

remote_temp=/tmp

global_conf

This is the global configuration file. If set, this file will be added to the ghettovcb command using the -g . The file must be in the local directory.

global_conf=ghettoVCB.conf

script

Default is ghettoVCB.sh. the is the name of the script in the localdirectory. This allow you to easily mix original and custom version of the ghettoVCB.sh script. Sometime MagiKmon provides a custom version of the script to fix some issues, see more on the download page.

script=ghettoVCB.sh

vm_list

This is the list of all VM you want to backup. Name must be separeted by spaces. Virtual machine having spaces (what is a very very bad idea) must be enclosed into double quote (")

If the parameter is missing or if the list is empty, MKSBackup will backup all VM at once using the -a switch. This will generate a unique report for all VM. VM can be excluded using the vm_exclude parameter.

vm_list=first second "the last one"

vm_exclude

If the vm_list is empty, this is a list of the VM excluded from the backup. Name must be separeted by spaces. Virtual machine having spaces (what is a very very bad idea) must be enclosed into double quote (")

vm_exclude=excluded_vm another_excluded_vm

destination

This parameter specifies where files will be copied using SSH or FTP after the backup. This parameter follows the destination syntax. If not specified, MKSBackup do a normal ghettoVCB backup.

This back-end allows to use FTP url, but If normal file path are used, SSH will be used instead. FTP allows files upload to another host, SSH is limited to localhost.

destination=<backup=mon-fri>
            <copy=sat>c:\tmp\vmware\${vm}-${nweekdayname}
            <copy=sun>ftp://john:secret@192.168.1.102:21\backup\vmware\${vm}-${nweekdayname}

Allowed types are :

The copy and move actions are ignored for machine backed up on non persistent NFS store !

The copy of the file can be very slow, ESX(i) is not expected to be very fast when doing an SCP transfer. FTP is a lot faster!

The front-end allows to use additional variable ${vm} to differentiate between virtual machines.

ftp_local

This allow to configure the built-in ftp server. More in section FTP upload.

ftp_local=ftp://192.168.1.100/D/vmbackup

scp_bin

This is the location of the scp utility you will use to transfer your backup file up to your local host. If you set this parameter, MKSBackup will check if the file exist, even if you don't need it !

Additional parameteters can be added on the line. String containing space must be quoted using double quotes.

The python's paramiko's ssh functions are fast enough to upload small files and start the ghettoVCB script, but proved to be very slow to download the large backup files. The popular putty for Windows and the standard openssh provided with all GNU-Linux OS will perform a lot faster.

Both have the use to check the server's host key before to connect. This is why you have to connect manually at least once using ssh or scp to register the host key in the cache before to use MKSBackup. Be careful to use the profile of the user you will use for the scheduled backup.

Because openssl don't allow to set the password on the command line like putty, you need to use authentication key to allow unattended connection as required by MKSBackup. You need to generate and key pair and add the public one to the /.ssh/authorized_keys file on the ESX(i) server. You can find more about this in the Getting started section.

On Windows, after having installed putty or just copied PSCP, set the path of the pscp.exe binary into the scp_bin variable. Sometimes the -scp option can be used to force the use of the SCP protocol.

scp_bin="C:\Program Files\PuTTY\pscp.exe" -scp

On Linux or Un*x compatible system, set the scp path like this.

scp_bin=/usr/bin/scp

Mail report

The mail report reproduce the usual structure but also includes following attachments.

output.txt

This is the output ghettoVCB.sh command. The time is usually in the UTC time zone.

2010-03-30 06:13:05 -- info: === ghettoVCB LOG START ===
2010-03-30 06:13:05 -- debug: HOST BUILD: VMware ESXi 4.0.0 build-164009
2010-03-30 06:13:05 -- debug: HOSTNAME: esxi.asxnet.loc

<snip>...</snip>

done.
Clone: 100% done.
2010-03-30 06:14:22 -- info: Removing snapshot from fc6pmx ...
2010-03-30 06:14:28 -- info: Backup Duration: 1.32 Minutes
2010-03-30 06:14:28 -- info: Successfully completed backup for fc6pmx!
2010-03-30 06:14:28 -- info: === ghettoVCB LOG END ===

dir-${VM}.txt

This is the listing of the target directory. Not available when backup occure on non persistent NFS store.

-rw------- 1 root root 4294967296 Mar 30 06:13 fc6pmx-flat.vmdk
-rw------- 1 root root 498 Mar 30 06:14 fc6pmx.vmdk
-rwxr-xr-x 1 root root 2484 Mar 30 06:13 fc6pmx.vmx

dirup-${VM}.txt

This is the listing of the parent of the target directory. Not available when backup occure on non persistent NFS store.

drwxr-xr-x 1 root root 700 May 20 16:37 fc6pmx-2010-05-20_16-37-17
drwxr-xr-x 1 root root 700 May 20 16:46 fc6pmx-2010-05-20_16-46-33

df.txt

This is disk usage of your ESX(i) server.

Filesystem 1k-blocks Used Available Use% Mounted on
visorfs 221116 186512 34604 84% /
vmfs3 15728640 12969984 2758656 82%
     /vmfs/volumes/4970f796-06563af5-553e-000e0c727dba
vfat 292752 235744 57008 81%
     /vmfs/volumes/efd8efe3-03bc1cbf-15e0-080efd9e7379
vfat 255716 60696 195020 24%
     /vmfs/volumes/bb133a7e-23390ed6-1354-1f507a206c7a
vfat 255716 4 255712 0%
     /vmfs/volumes/849b3a7e-07822ce3-43d8-b1ade310e088
vmfs3 487325696 175240192 312085504 36%
     /vmfs/volumes/4a202800-28e1d9fb-7ff0-000e0c727dba

ls_volumes.txt

This is a lising of /vmfs/volumes directory to match the symbolic links and the df.txt above.

== directory /vmfs/volumes
drwxr-xr-t 1 root root 1260 Mar 28 18:42 4970f796-06563af5-553e-000e0c727dba
drwxr-xr-t 1 root root 4620 Jul 16 16:05 4a202800-28e1d9fb-7ff0-000e0c727dba
drwxr-xr-x 1 root root 8 Jan 1 1970 849b3a7e-07822ce3-43d8-b1ade310e088
l--------- 0 root root 1984 Jan 1 1970 Hypervisor1 -> bb133a7e-23390ed6-1354-1f507a206c7a
l--------- 0 root root 1984 Jan 1 1970 Hypervisor2 -> 849b3a7e-07822ce3-43d8-b1ade310e088
l--------- 0 root root 1984 Jan 1 1970 Hypervisor3 -> efd8efe3-03bc1cbf-15e0-080efd9e7379
l--------- 0 root root 1984 Jan 1 1970 SATA500-0 -> 4a202800-28e1d9fb-7ff0-000e0c727dba
l--------- 0 root root 1984 Jan 1 1970 SATA750-0 -> 4970f796-06563af5-553e-000e0c727dba
drwxr-xr-x 1 root root 8 Jan 1 1970 bb133a7e-23390ed6-1354-1f507a206c7a
drwxr-xr-x 1 root root 8 Jan 1 1970 efd8efe3-03bc1cbf-15e0-080efd9e7379