Edit: I love talking about Redbooks.
Originally posted January 12, 2010 on AIXchange
A new Redbook, “PowerVM Migration from Physical to Virtual Storage,” is coming out soon.
The concepts covered here are critical to understand. Whether you’ve been virtualizing for years or you’re just getting ready to take the plunge, you need to know all of the options for migrating physical disks to virtual disks. I believe this Redbook can help.
One of the first things I noticed on pages 6-7 is a handy chart that’s designed to help you choose the appropriate option for migrating a standalone server to a client LPAR on a consolidated frame. These option include:
* Backup to CD/Tape and Restore on Virtual I/O Server managed disk.
* Mirror rootvg disks to SAN disks.
* Cloning rootvg to an external SAN disk using alt_disk_install.
* Other methods such as NIM.
The chart as a whole allows you to navigate the publication based on your migration needs. For instance, the first column is called “Migration Objective.” By clicking the items in this column, you’ll jump to the chapter with information about the specific procedure (e.g., Chapter 3, “Standalone SCSI rootvg to virtual SCSI” on page 45).
The authors provide these additional steps for using the table:
“1. Learn how to use the virtual SCSI and virtual Fibre Channel methods as described in Chapter 2, ‘Core procedures’ on page 9.
2. Choose from what configuration you are migrating (Migration Objective column) – the cells in this column are linked to the actual procedures, thus, clicking the cells is another way to quickly move through the publication.
3. Choose what you are migrating (Volume Group to Migrate column).
4. Choose which procedure (Migration Procedure column) suits your environment and your administrator skills.”
Finally, the authors make these general recommendations for performing any data migration:
“1. Back up the client system: Prior to making any changes, it is recommended that the source standalone and/or dedicated partition be backed up. Some of the migration procedures can be used to perform this backup. All backups require validation to ensure they are restorable.
2. Back up the configuration of the Virtual I/O Server that you will be modifying — the viosbr command has been introduced to the Virtual I/O Server commands for this purpose.
3. It is always a best practice to perform the migration procedure on test systems and data before applying to a production environment.”
One reason I highlight this section is its mention of the viosbr command. This is fairly new, and I only recently tried it for the first time. When I tested the command, I received this error because I had some disks mapped that were defined instead of available:
$viosbr -backup -file /backups/testbackup
Device “vhost1” is not in AVAILABLE state.
Device “vhost2” is not in AVAILABLE state.
So, to make the viosbr command happy, I deleted the devices it was complaining about:
$rmvdev -vdev hdisk1
vtscsi0 deleted
$rmvdev –vdev hdisk2
vtscsi1 deleted
$rmdev -dev vhost1
vhost1 deleted
$ rmdev -dev vhost2
vhost2 deleted
With these items deleted, I was able to successfully run viosbr. At this point I had a file called testbackup.tar.gz. I went into my /backups directory and ran gunzip and then tar –xvf on the file — this allowed me to view the contents. It was an xml file that contained the information that would be needed to recreate my VIO server.
If you run $help viosbr as padmin on your vio server, you should see all the different available options. You can backup virtual and logical configurations, and list and restore the configurations of the VIO server.
I’d take some time in a test lab to get familiar with the different things you can do, including adding viosbr to crontab using the –frequency option. Next week I’ll cover some other information in this Redbook.