BMC VM Linux Management and Archiving Code

122 lines (90 with data), 6.2 kB

VMLMAT includes Multi-volume support 
Updated Ronnie Michael
Sept 28, 2008

Supports single or multi-volume Linux systems where the VM account uses minidisk for each 
of the various Linux mountpoints in /etc/fstab as /dev/dasdyx statements where
y is the drive letter and x is the partition number.

 All VMs  supported should be consistent with your standard images since it will effect the device name 
 to mount in /etc/fstab: /dev/dasda1 for example of single volume system. 


Program logic:

CMS Control Machine

BUILD exec allows for mdf (minidisk from address) and mdt (minidisk to address) to be specified in the hcp msg commmand

Copy Server

To submit a request to backup:

/var/clone/bkclone must read fstab and setup device names of /dev/dasdyx devices.
It is assumed that the first volume is the Linux / mountpoint volume and
therefore would allow reading the  /etc/fstab to find the rest of the device names.
From various parmfile values this first volume can be determined and its mdf value inorder to be mounted to
the Copy Server. 

bkclone must backup each volume as hostname_timestamp_volyx.tar
where y is the letter of the device and x is the partition number or zero.
This is done by having hcp msg commands in bkclone routine specify 
the link for each mdf (minidisk from)  mdt (mindisk to) pair, the chccwdev -e,
mount, tar, umount, chccwdev -d and then a detach of each.
The html form file is created and stores the hostname_timestamp prefix of the tarfiles. 

To submit a request to restore:

bkclone must read the parmfile arcpath directory, match hostname_timestamp prefix from the restore
html form (now in the request) to the file names in the archive directory. Then  
get the count of file name volumes, parse each file name for the y value from the 
hostname_timestamp_volyx.tar filename, and derive the
mdf from the mapping of atab/ntab of parmfile. The system issues the hcp msg
link for each mdf mdt pair, the chccwdev -e, mount, (optional diskfmt,fdasd), mkfs, 
tar, umount, chccwdev -d, and detach. It will do this for each of the volumes in the volume count.
Additionally, for the first volume which is assumed the Linux / mountpoint, the system 
will also run the change script and ZIPL for booting. 

Auto-Backup support also needs to delete all previous backup generated multi-volumes.
This is processed in /var/clone/bkclean.

User backups are deleted in /var/clone/bkgen as a request code 4. 

Operations and Limitations: 

The standard Linux images should have 15 contiguous hexadecimal addresses specified in 
/etc/zipl.conf as dasd=xx1-xxf where xx is the installation's choice of hexadecimal. 
These will be mapped to Linux devices /dev/dasdyx in fstab.

/etc/fstab must have this format:

/dev/dasdyx   where y should be the first char in parmfile atab and x is optional partition number for / mountpoint.
/dev/dasdyx   where additional lines like this are optional.
              and y is other device letters and x is partition number for other mounpoints.

Specify rpart in parmfile if the installation does partition the Linux / mountpoint volume. 

Note: The code uses this logic for backups when dealing with the very first volume assumed
to be the Linux / mountpoint:
We have to hard code the volyx value since we have not read the fstab yet.
Therefore, we will use the values from parmfile rpart and first entry of atab
with the device prefix of /dev/dasd
To setup mdf (minidisk from) address, we will use the parmfile mdlink and the first entry of ntab to
correspond with the the first atab entry. 

For example: 

Lets assume,
 The backup image have /etc/zipl.conf dasd=201-20F specified.
Copy Server installation parmfile has these values:
mdlink 209 (the copy server should share the same zipl.conf configuration as Client VMs)
rpart 1 (This says that / mount point is partitioned)
atab a,b,c,... (this specifies the device letters to suffix to /dev/dasd)
ntab 1,2,3,... (this specifies the third digit of the minidisk address as specified in zipl.conf dasd= )
dskfmt yes  (we would like to Linux format the volume each time)
mvol yes (we support multi-volume systems)

A Client VM has the following minidisk 201 and 203 on the VM account 

The backup image's, 
/etc/fstab might list the following:
     
     /dev/dasda1  / 
     /dev/dasdc1  /usr

Therefore from a prior backup, the above would yield a restore html tarfile name of hostname_timestamp
 (without any _volyx.tar suffix)
yet the /mnt/archive directory and routines would yield these tar files to restore:

  hostname_timestamp_vola1.tar
  hostname_timestamp_volc1.tar

and during the restore the Copy Server will link the client VM's 201 as 209 to the copy server,
bring it online, mount it, Linux format it, partition it, and makefs,
and restore hostname_timestamp_vola1.tar and prepare by running zipl and change scripts.
Then the Copy Server will detach 209 and link 203 as 209 to the copy server, Linux format it,
makefs, and restore hostname_timestamp_volc1.tar without Linux partitioning the volume in this case.

If parmfile mvol is yes then the user accepts that only like VM configurations are interchangeable with backups.
A 3 volume system can only be restored to 3 volume systems of the same device names. Example:
a backup of /dev/dasda1, /dev/dasdd, and /dev/dasdf1 can only be restored to a system with this same configuration.
Remember /dev/dasda1 is assume the Linux mountpoint of /.
If parmfile mvol is no, then only single volume support is given and all VM configurations could therefore be the same and interchangeable. Example: all systems have only a /dev/dasda1

 check to see if first volume i = 0 and mvol = yes (we support multi-volumes), 
 if so we need to read fstab to see if this is a multivolume system
 Typical problems are related to mvol yes and not specifying fdev correctly or that your 
 backups don't consistently agree with fdev value.

You must be consistent with the mkfs command and what is recorded in fstab.
A common mistake is to backup an ext2 system and restore via the vmlmat parmfile fsmake parameter
a mkfs.ext3 so that the file system will not mount via the backup's fstab entry.