With the release of IBM i version 7.2 Technology Refresh 1, Big Blue has reduced the size requirement for the load-source disk for virtualised storage implementations.
“So what?” I hear you cry. “All my disks are physical, they are bigger than 70GB and have been for years. What’s the big deal?”
Well, for production workloads, you are quite right. If you are running 7.2, you must be on at least a Power6, so the chances are that your disks are 70GB or larger. But if you are one of the many that are still considering upgrading to 7.2 and you want to upgrade your test system to it or create a new test system for it, then this is where TR1 really can help.
Here is an example of what I am talking about, based on one of the upgrades I was carrying out for a friendly customer over Christmas (Hi, Will). This client has a small Power7+ server with two LPARs – Production and Dev.
Like many companies of this size they have all their physical storage allocated to their Production LPAR and carve out virtual disks for the Dev server from this Production server using the IBM i-hosting-IBM i methodology.
As their Dev system has a much smaller data set, it really does not need much space. So the idea of having to allocate 80GB virtual disks (IBM’s former recommended minimum) from the host was, at best, wasteful and, at worst, a cause for them to need a disk upgrade.
What’s actually changed in TR1? If you use a v7.2 TR1 i_Base_1 image for your install or upgrade to v7.2 and your disks are being presented by either VIOS or IBM i-hosted Network Storage Spaces, then your virtual disks need only be 35GB* rather than the previous requirement of 70GB*. My asterisks here denote usable size by client LPAR. IBM recommends that you allocate 40GB and 80GB respectively on the host to allow for losses due to formatting.
What’s the difference?
So why is there a difference between the pre- and post-formatted size? As you probably know, you always lose some of the native capacity of any disk when you format it. The process writes out data onto the disk to describe where and how the data will be stored. However, in this case, this is further compounded by sector size mapping.
Traditional internal IBM i disks use a 520 byte sector size but pretty much everyone else uses 512 byte sectors and both VIOS and IBM i Network Storage Spaces use 512 byte sectors. The way IBM i deals with this is to borrow from the following sector. Consequently, a 40GB network storage space (virtual disks) on the host LPAR turns into a 37GB disk in the client LPAR using it.
There is good news, though, as in this case you do not have to protect these virtual disks with RAID. They are already protected from disk failure by the host’s RAID configuration, so you don’t lose any usable disk space on the virtual disks for data protection. Generally, this means fewer disks, less rack space and lower running costs.
In the following example, we see the a set of virtual disks as they are allocated on the host IBM i LPAR and as they appear on the IBM i client LPAR. You will see on the host side they show as 30725MB and on the client (after formatting) they show as 28638MB, so we lose around 7% to formatting; way better than the 50% to RAID1 or the typical 12.5% to RAID5 or 25% to RAID6.
The bottom line is that if on the client side you see that all of your disks have 35GB or more, then you are good to upgrade using the v7.2 TR1 iBASE without any further thought to supported load-source size. If they have 70GB or more, then you can use any v7.2 iBASE image.
What if you have already created a load source less than 35GB? As you can see from the example above, this was the position I found myself in over Christmas. I had an IBM i-hosting-IBM i LPAR running on 6 x 30GB virtual disks (before formatting) which equated to 28.6GB disks on the client LPAR. The good news is that you don’t have to scratch and reinstall the LPAR to upgrade it.
This is where is gets a little techie, so if you don’t have this problem or you have a life or work to attend to then you are excused from reading the following. But if you’ve ever wondered how to migrate your load source to another disk, whether it be physical or not, then the latter part of this procedure will show you how you can do this.
At this point I need to caution you. If you mess this up, you will be reloading your client LPAR so make sure you’ve got a current SAVE 21 backup before you start. The good news is that it would be really hard for you to mess up the hosting LPAR, so the risk is mostly limited to the client. Also, I have to point out this is my interpretation of IBM’s guidance and you can always check with them if you want to be sure.
Finally, you will need to know your way around DST but, hey, what better way is there to learn other than on a test system? Now that I have given my disclaimer, let the fun commence.
How do you work out which virtual disk is your load source? First of all, you need to know which of the Network Storage Spaces on the host is housing your load source, as this is the only disk that needs to be resized. Let me say that again, it is ONLY the load source disk that has to be 35GB or larger; the rest of your disks can be smaller.
To work this out, you need to know three things:
• Firstly, which disk does the client LPAR think the load source is on? 99 times out of 100 it will be disk unit 1, e.g. DD001, but if you need to check, go into SST, Start a Service Tool, select Hardware Service Manager, Locate Resource by name, type DD001. If it is the load source, you will see it has an * next to it.
Tip: Right now there is a “feature” that stops disks being listed on rack configs for v7.2-hosted LPARs, so you can’t use that method to identify load source. Hopefully, by the time you do this, IBM will have fixed it.
• Secondly, on the client LPAR, what is the Ctl value of the Load Source Disk? 99 times out of 100 it will be that Ctl = 0 but if you need to check, go into SST, Work With Disk Units, Display Disk configuration, Display disk configuration status, identify your load source in the list and press F9 to get Disk Unit details and note the Ctl value. For clarity, in the screenshot below I’ve merged the two F9 views so you can see Ctl value and Resource name on same page. You will see them separately but you get the idea.
• Thirdly, on the host LPAR, what is the sequence that the storage spaces are presented? Usually Seq = 1. Use the WRKNWSSTG command to get a list of the storage spaces linked to your guest LPAR.
As you may have guessed, the sequence that the host LPAR presents the virtual disks (in this case network storage spaces) matches the ascending order of the Ctl value on the client LPAR. Just to be slightly annoying (or truly IBM as I like to put it), the former starts the count from 1 and the latter from 0.
So, in our case:
• DD001 is our load source
• It has a Ctl value of 0, the lowest number
• So load source must be the network storage space with lowest sequence 1 number, i.e. GBLVTEST00.
How do you migrate the load source?
Now you know where the load source is, you can migrate it using the following procedure:
1. On the host LPAR, create a new network storage space of at least 40GB to house the new load source. Tip: Check your have plenty of free disk space on the host to house this new load source; keep it under 75% if you can for best performance.
2. On the client LPAR, backup with a SAVE 21 and power it down
3. On the host LPAR, vary off the hosting network server description and link your new network storage space to the guest LPAR in the next free sequence slot, in this case 7.
Vary on the hosting network server description.
4. On the client LPAR, set IPL mode to Manual and IPL to DST. Your new network storage space should show up as non-configured in the disk; in this case, DD007.
Copy disk unit data from current load source (DD001) to new non-configured disk (DD007) using the Copy Disk Data Unit Data option (you can find this DST option in Work with disk units, Work with disk unit recovery).
Once this has successfully completed, you can power down the client LPAR again. Tip: If you are using this procedure to copy/move a protected or physical load source disk, you need to take a few extra steps. These are detailed on IBM Knowledge Center here.
5. On the host LPAR, vary off the hosting network server description. Unlink the old load source storage space, noting its sequence number (in this case 1). Unlink the new load source storage space, noting its sequence number (in this case 7). Link the new load source storage space using the sequence number of the old one (in this case 1). Vary on the hosting network server description
6. Set your client LPAR back to Normal IPL mode and IPL it and this time you should have your newly enlarged load source. It will probably report in as DD007. That’s normal. IBM i is like an elephant, it never forgets.
You are now ready to upgrade to v7.2 TR1. I did warn you this one got a little techie.
So much more to say
I think it’s fair to say that many HMCs don’t get the love and attention they deserve. In fact I’m teaching a course on how to love your HMC next week. In a future article, I will share a few tips and tricks with you from this course but if you have something in particular you’d like me to discuss, you can contact me via the feedback below or through my website here.
Our next i-UG meeting will take place in at the Norton Grange, Rochdale, UK on 19th February. We’ve already confirmed a number of excellent guest speakers including: David Spurway, who will demonstrate how buying a Power 8 can be cheaper than keeping your current server; Andrew Ireland, who will be showing you the latest and greatest from Web Query; Kevin Askew who will be doing a show-and-tell on 3D printing; and last and by all means least, I will be talking about performance monitoring.
Hope to see you there, more details at the i-UG website.
Steve Bradshaw is the founder and managing director of Wolverhampton, UK-based Power Systems specialist Rowton IT Solutions and technical director of British IBM i user group i-UG. He has been a key contributor to PowerWire since 2012 and he also sits on the Common Europe Advisory Council (CEAC) which helps IBM shape the future of IBM i.