AIX Down Under

Correspondendo a: aix

UPDATED: Migration to AIX 7.1 in 35 minutes

AnthonyEnglish Marcações: vios installation virtual_media upgrade file_backed power aix download vmlibrary migration vio_server iso ‎ 5 Comentários ‎ 49.766 Visualizações

Virtually converted to AIX 7

I just did my first migration of an LPAR to AIX 7.1. I chose to migrate my AIX 6.1 NIM server.

I first downloaded AIX 7.1 from the Entitled Software Support web site.

I copied the two ISO images to the Virtual Media Library on the VIO server, and I broadly followed the procedure outlined by my compatriot Chris Gibson in his article AIX Migration with File-Backed VIOS Devices. I gave the two ISO images shorter names when I copied them into /var/vio/VMLibrary. You can also rename them using the VIO server mkvopt or chvopt commands.

The fine print

All up, the migration took about 35 minutes from the SMS menus to the login prompt following the reboot. I migrated from AIX 6.1 on a virtualised LPAR (no dedicated physical adapters) and there were 555 filesets to install. Most of my time was spent speed reading copyright notices.

Hardware requirements

Given my reluctance to open data centre doors, and the fact that it's spring in Sydney so I didn't bring my winter woollies with me, I decided to do it all from the comfort of my desk.

Here is the list of hardware I was in physical contact with:

a keyboard
a mouse
a chair
a coffee cup

df shows free space (see update below)
After the reboot, I noticed a small but significant change to the df command in AIX 7. It now displays free space by default, without using the -I flag. I still like to have the sizes in Gigabytes, so I used df -g

# df -g
Filesystem    GB blocks      Free %Used    Iused %Iused Mounted on
/dev/hd4           0.38      0.17   55%    10177    18% /
/dev/hd2           2.00      0.32   84%    41293    30% /usr
/dev/hd9var        0.56      0.22   62%    12238    17% /var
/dev/hd3           1.06      1.06    1%       69     1% /tmp
/dev/hd1           0.06      0.06    1%       13     1% /home
/dev/hd11admin      0.12      0.12    1%        5     1% /admin
/proc                 -         -    -         -     - /proc
/dev/hd10opt       4.94      1.34   73%    98194    20% /opt
/dev/livedump      0.25      0.25    1%        4     1% /var/adm/ras/livedump
/dev/fslv01        0.12      0.04   65%       13     1% /tftpboot
/dev/eznim        16.00      5.74   65%    64201     5% /export/eznim

Update:

The default output of the df command hasn't changed from AIX 6 to AIX 7. It just took me to do a migration to notice!

AIX 7 migration - a positive experience

It was a very straightforward migration with no surprises, apart from some warnings about missing filesets to do with virtual devices. I ignored them and they went away (the warnings, not the devices).

I am tempted to use the VM Library rather than NIM for the other LPARs I have to do, as most of the LPARs are on the one physical server and are clients of the same VIO server.

Installing AIX 7.1 was a very positive experience.

From my desk in the remote antipodes, I'm reaping the benefits of virtualisation on IBM Power Systems. Looks to me that IBM has done a great job with AIX 7.1.

UPDATED: AIX 7 features for AIX 6

AnthonyEnglish Marcações: ssd mkvg topas solid_state_disk aix_6.1 pv vscsi features vios wpar aix7 aix_7.1 aix6 aix filemon 7 ‎ 12.659 Visualizações

UPDATED: Chris Gibson has pointed out a couple of other AIX 7.1 features which have been backported to AIX 6.1 from TL 6.

topas screens now allow a freeze / unfreeze by hitting the spacebar
In topas you can also page down and page up through the data

For more details, see the comments in my post: topas features: sort by column, toggle to nmon or check the AIX 7.1 Differences Guide

If you’re looking forward to some of the new features of AIX 7, but find migrating to the new release a little daunting, then it's time for you to put into practice the underlying principle which drives Australia:

relax!

Why? Because some AIX 7 features will be backported to AIX 6.1 TL 6!

IBM is getting really smart at listening to the needs of the AIX community. We've seen (and participated in) the open beta program for AIX 6 and now for AIX 7. And now, we're seeing more and more where new features which are really helpful are backported to the most recent TLs of earlier releases. This is

jolly good news

Here are two AIX 7 (and AIX 6.1 TL 6) features you might be interested in:

volume groups just for Solid State Disks
and VIO scsi support for WPARs

Solid State Disk Volume Groups

From AIX 7, and in AIX 6.1 TL 6, there is the ability to create a volume group restricted to a certain PV type, such as Solid State Disks. You might use this for very high usage disks which you typically would like to isolate from other disks. Oracle redo logs would be a prime candidate.

When you run the AIX 7 mkvg command, you can set a PV condition using the –X flag. The default is “none”, which means you can mix and match PV types in the same VG. Or you can use –X SSD to guarantee that slower, non-SSD, disks can never be added to your VG. Here's what the syntax of mkvg looks like under AIX 7.1:

Usage: mkvg [-B] [-G] [-f] [-C | -c] [-i] [-s PPsize]

[-n] [-t factor] [-V MajorNumber] [-L LTGsize] [-I] [-M {y/s}]

[-S [-v LogicalVolumes] [-P Partitions]] [-X {none/SSD}] [-y VGname] PVname...

Makes a volume group.

You'll also be able to report per-file statistics to identify the hot files which might be good candidates for SSD disks. The filemon command has been enhanced for reporting these hot files.

vscsi disk support for WPARs

From AIX 7.1 (and back ported to 6.1 TL 6) you can export a disk from the VIO server to a WPAR. You might like to do this to map a rootvg or a data disk for the WPAR.

Although WPARs haven't taken off quite as they might have, it's probably worth looking at them now, especially if your environment has a large number of LPARs.

Not such a jump from 6 to 7

The jump from AIX 6 to 7 doesn’t seem to be anywhere near as big as from 5.3 to 6.1. Even so, there are people who prefer to wait a few months before going to a new release. If you want to dip your toes in, you can upgrade to AIX 6.1 Technology Level 6 and still get some of the new AIX 7 features.

Resources

Overview of new AIX 7 features and functions:

http://www.ibm.com/developerworks/aix/library/au-aix7overview/index.html

AIX 7 webinar (90 minutes) with Jay Kruemcke:

http://www.ibm.com/developerworks/wikis/display/WikiPtype/AIX+Virtual+User+Group+-+Central+Region+USA

DR across the drink - virtualisation helps earthquake victims

AnthonyEnglish Marcações: remote disaster_recovery aix christchurch dr support nz new_zealand earthquake ‎ 7.916 Visualizações

You would have heard by now of the earthquake in Christchurch, New Zealand on Saturday. It was 7.1 on the Richter scale and remarkably – I would say miraculously – there have been no deaths directly from the earthquake reported so far. As the Sydney Morning Herald reports,

Haiti - which was hit by a strike-slip fault that caused a 7.0 magnitude quake last January - suffered the loss of at least 220,000 lives.
New Zealand, which also experienced a strike-slip fault between the Pacific plate to the east and the Australian plate to the west, recorded no fatalities.
Only two people were seriously injured.

Anywhere but here

Although Christchurch is the largest city on the South Island of New Zealand, from my experience, larger companies in NZ work primarily out of Auckland, the largest city in the North Island.

Very often NZ users connect to systems in Australia. Not too far away, as you can see on this map.

NZ is two hours ahead of Sydney, where we often host systems and arrange occasional outages with hopefully not too much inconvenience to the Kiwis. They don't complain too much anyway. This remote hosting of systems has been crucial for some insurance companies working out of Australia and New Zealand, especially in the aftermath of the earthquake. Thankfully, there have been no deaths directly from the earthquake, but infrastructure has been hit hard. In an event like that, you'd be glad to know a company's main systems, and a reliable DR, are far away from you ... and from each other.

"G'day, Kiwis!"

Over 50 of the buildings in the Christchurch Central Business District have been substantially damaged. Roads are often unpassable, water and electricity is still sporadic. With all of these factors, when you want to place a call to get some help from your insurance company, you hope their systems are not down. If your city has been hit by an earthquake, it's good to know that your company's Production systems are hosted somewhere else. A Disaster Recovery plan may not even need to be implemented. You call your insurance company and a friendly Aussie voice on the other end will hopefully be there to say Good day ("g'day"), ready to listen and help.

Some insurance companies I have worked with have taken great advantage of virtualisation. Comms links being what they are these days, you can easily consolidate and virtualise your systems to work out of a different country. When you have to place that sad call to say your house or business premises were wiped out by an earthquake, it’s a great relief to know that the insurers' systems are on the other side of the Tasman Sea, or “across the drink”, as we say.

“Good as gold”

Sometimes the work we do on AIX systems doesn’t seem so important. When a tragedy like this occurs, we realise that the work we did retiring a standalone box in a remote location, or migrating that web server and database to newer hardware in a secure data centre – means that real people can start the business of rebuilding their lives a little more easily. You also understand why the DR centre had to be distant from the prod site.

My prayers go to the many people who will have to rebuild their lives after this tragedy. The habitual cheerfulness and resilience of the Kiwis makes them a delight to work with. I am sure it's what will carry them through following the earthquake. As they like to say in NZ, I hope that before too long everything will be “good as gold.”

Is your AIX system clocking up overtime?

AnthonyEnglish Marcações: virtual_loaner_program topas vlp aix lpar busy performance vmstat tuning statistics uptime free_pages virtual_memory iostat earl_jew paging oracle memory nmon ‎ 12.467 Visualizações

WHAT A PERFORMANCE!

Many performance commands such as vmstat and iostat can report accumulated statistics since the last reboot. So it's important to know when that reboot happened. The uptime command will give you that information.

Here is the result of running uptime on an LPAR I'm using via the IBM Virtual Loaner Program:

lpar05p682e_pub[/] > uptime

04:45AM up 2 days, 5:08, 1 user, load average: 1.00, 0.75, 0.66

The LPAR has been up for 2 days (and 5 hours, 8 mins) and there is just one user logged in. (I like my personal space.)

The load average from the uptime command shows the total number of runnable processes in the last 1 minute, 5 minutes and 15 minutes. So uptime gives you a quick glance of the system, without running more detailed commands such as topas or nmon. (Those last two commands in AIX 6.1 are actually the same executable, and you can toggle between topas and nmon screens using the tilde ~ key).

Watch out for the RAM page!

Although uptime is helpful, it really is only a quick snapshot. When poor performance is being reported, you really need to drill down some more. One of the commands you can use is vmstat -s which, as the documentation explains, shows you "an absolute count of paging events since system initialization". (A "page" is a page of virtual memory, not just paging space.)

A clock doing overtime

vmstat -s can really highlight some serious issues. Take a look at this Oracle LPAR, for example:

The uptime command shows it's been up for just 10 days:

09:14PM up 10 days, 11:42, 3 users, load average: 1.86, 1.61, 1.58

The vmstat -s command shows (among other things) that in that time there were

2259 revolutions of the clock hand

This is

less than optimal

In fact, it's what you might even call bad.

A revolution of the clock hand means that in the 10 days of uptime, the system had to scan the whole of the system's memory for something free 2259 times. That's about 225 times per day, or between 9 and 10 times per hour.

Earl Jew's Performance Tuning

That's not the whole story about memory, of course. If you want to know more about vmstat and other key performance tuning commands, you could refer to the AIX 5L Performance Tuning Redbook. Still relevant, even though AIX 7 is about to be released.

I also recommend you watch Earl Jew's excellent presentation on AIX Tuning. It's amazing how much Earl packs into 90 minutes. He outlines some really important performance tuning principles and then explains - with examples - some of the bottlenecks you're likely to see.

You can download a replay of that presentation from the AIX Virtual User Group - USA (originally known as AIX Virtual User Group - Central Region - USA)..

Go to the session marked:

July 29, 2010 - AIX Tuning with Earl Jew

There is also a script which you can run and a very detailed explanation of all of those puzzling numbers from vmstat, iostat, lparstat and a few other key performance commands. Earl does amazing comparisons between values and explains just how concerned you should be when you see a statistic like

70593409 paging space page outs

(Hint: have an ambulance on standby).

Geek Trivial Pursuit: one-character commands

AnthonyEnglish Marcações: one-liners aix one-character geek_party_tricks command ‎ 3 Comentários ‎ 10.054 Visualizações

Better than one-liners

Unix commands are cryptically brief at times. That's to save you typing. Well, knowledge is power and you can turn your knowledge of AIX commands to your advantage.

Next time you're at a Geek Party and it comes time for trivial pursuit, you can impress your many friends with this question:

What are the shortest commands in AIX?

f - shows user inforrmation (same as the finger command)
w - prints a summary of current system activity.
X - starts the X Server.

See if you can memorise those answers. It will increase your chances of winning that

"Get-a-Life!" t-shirt

And did you know that there's a command called yes and another called no? Or that you can do a false alarm shutdown using shutdown -k? Ha, ha, ha! That's a beauty. Won't the users love that one!

Combine this with the supergeek party trick with the cd command we saw here, and you're guaranteed to have a great time at that party, aren't you?

No, don't thank me for these

great, fun tips!

Just send me a photo of you wearing your new t-shirt.

The AIX LVM - a perfect gentleman

AnthonyEnglish Marcações: mount_point logical_volume mksysb lv chfs importvg chlv volume_group rootvg gentleman exclude.rootvg exportvg tsm aix manners file_system ‎ 19.729 Visualizações

Diamond in the SAN

I recently cloned an LPAR from a P6 to a less-busy P5 server via a mksysb backup. Unfortunately, after starting up the new LPAR I found that there was an essential directory missing because it had been excluded via the /etc/exclude.rootvg file (-e option on mksysb). Let's call the directory /diamond (its name has been changed to protect the guilty who didn't back it up).

I considered my options but each of them had a drawback.

Option 1: restore directory contents from TSM
Obstacle: unfortunately, the directory had been excluded from the TSM backup.

Option 2: shut down the new LPAR, bring up the old LPAR on the original SAN LUN and redo the mksysb
Drawback: time consuming

Option 3: bring up the old LPAR in single user mode
Drawback: I wouldn't have had a network connection to copy the files across to the new LPAR

Option 4: map the old SAN LUN to the new LPAR and import the old rootvg as a different volume group
Drawback: overwrites LV names on old rootvg LUN.

I went with option 4, which allowed me to dig out the treasured directory's contents from the SAN. It did have the drawback that it would rename logical volumes on the original SAN LUN. I was willing to take the risk. It wasn't likely I would need to boot off that LUN again. Even if I did have to, I could always rename them via SMS in single user mode before mounting file systems.

I had to get the old rootvg onto a live AIX LPAR. Here's how I did it.

An import-ant command

After mapping the old SAN LUN to the new AIX LPAR, I used importvg to import the old LPAR's rootvg under another name - oldrootvg

newhost:/ # importvg -y oldrootvg hdisk3
0516-530 synclvodm: Logical volume name hd5 changed to bootlv00.
0516-530 synclvodm: Logical volume name hd6 changed to pagelv00.
ln: 0653-421 /dev/ipl_blv exists.
Specify -f to remove /dev/ipl_blv before linking.
0516-530 synclvodm: Logical volume name hd8 changed to loglv02.
0516-712 synclvodm: The chlv succeeded, however chfs must now be
run on every filesystem which references the old log name hd8.

I got some warnings which I had to deal with before getting access to the contents of the directory I needed. The first was to do with LV names, the second was mount points. Here are the details,

LVM's good manners

When you're importing a rootvg (under a different name) onto a running LPAR with its own active rootvg, there are bound to be duplicate file systems and logical volumes. Fortunately, the AIX Logical Volume Manager (LVM) shows a bit of respect - the active LPAR's file systems and LVs don't get overwritten. The new guest LUN isn't allowed to push in. Instead, if there any conflicts, the imported VG gets new LV names. So when I ran importvg, hd4 was renamed to fslv02:

0516-530 synclvodm: Logical volume name hd4 changed to fslv02.
0516-530 synclvodm: Logical volume name hd2 changed to fslv03.
0516-530 synclvodm: Logical volume name hd9var changed to fslv04.
0516-530 synclvodm: Logical volume name hd3 changed to fslv05.
0516-530 synclvodm: Logical volume name hd1 changed to fslv06.
0516-530 synclvodm: Logical volume name hd10opt changed to fslv07.

Here's where the LVM showed itself to be a perfect gentleman. Good guests don't push people out of their own homes.

Moving mountains

As for file systems, I got a warning about duplicate mount points that needed to be fixed before mounting the old rootvg's file systems:

imfs: Warning: mount point / already exists in /etc/filesystems.
imfs: Warning: mount point /usr already exists in /etc/filesystems.
imfs: Warning: mount point /var already exists in /etc/filesystems.
imfs: Warning: mount point /tmp already exists in /etc/filesystems.
imfs: Warning: mount point /home already exists in /etc/filesystems.
imfs: Warning: mount point /opt already exists in /etc/filesystems.
oldrootvg

The logical volume for the file system I needed had been renamed from hd4 to fslv02, but the mount point was still set to /, so I had to change that for the newly named logical volume:

chlv -L'/mnt/oldroot' fslv02

At this point I created a new jfs2 log in smit lv (type jfs2log). I then set the jfs2log for my "new" root file system:

chfs -a log=/dev/loglv02 /mnt/oldroot

Finding that mount

The mount point /mnt/oldroot didn't exist, so I created the directory.

mkdir -p /mnt/oldroot

I could then mount the file system /mnt/oldroot, and recover the contents of /mnt/oldroot/diamond.

I then cleaned up the oldrootvg using umount, varyoffvg and exportvg and rmdev of the disk. I then unmapped the SAN LUN which was no longer needed on the new host and was able to start the database.

I fixed the /etc/exclude.rootvg (and the TSM inclexcl file, just to be safe) and gave a quiet thanks that when importing the rootvg into an existing running LPAR, the LVM had acted as a perfect gentleman.

From Breakfast to Bridge to Empire

AnthonyEnglish Marcações: aix sydney bridge harbour storage mark_chandler optimisation aixplode ‎ 6.219 Visualizações

Breakfast near the Bridge

I'm planning to be at the IBM Storage Optimisation Breakfast in Sydney on ~~Thursday~~ Tuesday 31 August 2010.

https://www-950.ibm.com/events/wwe/grp/grp018.nsf/v16_agenda?openform&seminar=ZAQ9FDES&locale=en_AU

If you're planning to be there, I'd be glad to catch up. It's at a hotel right in the heart of The Rocks, which is rich in Australian convict history. It's also about 5 minutes' walk from the Sydney Harbour Bridge. In Sydney we just call it "the Bridge" (not the coat hanger).

The pouring of the first steel casting was done in 1925 (see photo). More info about the Bridge is here.

Building bridges and empires

We in Australia have just taken a second step in our shameless effort to build world domination in the AIX space. A colleague of mine here in Sydney - Mark Chandler - has started his own blog called AIXplode. If you appreciate my sense of humour, well maybe you'd like to become a follower of AIXplode as well.

Mark's first blog post was on the VIO server shell prompt so you can work out whether you're logged in as root or padmin, and keep a shell history with it. This is a follow-up from Rob McNelly's AIXchange post on the VIO server padmin .profile.

UPDATED: MPIO Health Check? Wait a minute!

AnthonyEnglish Marcações: path mpio no_reserve lun pvid health_check single_path lun_id enabled chdev hcheck_interval status aix chpath reserve_policy vio lspv failed ‎ 23.256 Visualizações

REDUNDANCY? YOU CAN SAY THAT AGAIN.

In a dual-path VIO Server configuration, your SAN LUNs are (hopefully) protected from disk failures by being part of a RAID set of some kind. Ideally you've also got redundancy of adapters, switches, power and .... well a lot can go wrong, can't it? That's why you protect yourself from any component being a Single Point of Failure (except yourself, of course.)

One VIOS down, all LUNs up

But what about the VIO server itself? If you have an outage of one VIO Server, you still want your VIO clients to see all of their LUNS through the second VIO server. (A dual VIO Server configuration is only available if you have an HMC. IVM is by its nature, a single VIO system). With two VIO Servers, you can present each LUN to both VIO servers via MPIO (Multi-Path I/O). Then the VIO client (for example, the AIX LPAR) can see the same LUN through two paths. If a VIO server should get rebooted, usually for an upgrade, the disk at the VIO client will simply lose one path to the LUN, and still be able to access the LUN through the other path.

"I've lost my path"

Supposing one VIO server goes down. On the AIX LPAR, the lspath command would show that one path has failed, such as the one on virtual scsi adapter vscsi0. In the following example, vscsi0 is the virtual SCSI adapter which goes through VIO server 1:

Failed  hdisk0 vscsi0
Enabled hdisk0 vscsi1

Once the VIO server is back up again, and its access to the LUNs is reinstated, you could log onto the LPAR and set the status of the path to "enable" again using the chpath command:

chpath -l hdisk0 -p vscsi0 -s enable

and do the same for each LUN on the other 30 LPARs until your fingers drop off.

Or you could

wake up that little man inside

"What little man?"

You studied computer science and they didn't tell you? There's a little man inside your computer system who will wake up every 60 seconds and look out the window to see if that second path has turned up again. I say make him sing for his supper. You don't buy a dog and bark yourself, do you?

To get him to do this, you just have to ask him nicely by setting the health check interval on the disk. You do this on the VIO client (the LPAR) using chdev (not chpath):

chdev -l hdisk0 -a hcheck_interval=60

If you get an error on that command saying that the device is busy, it's probably because it's in a volume group. Here are a few ways around it:

Option 1: set it for the next reboot

You can set the change in the ODM using the -P flag. This sort of means permanent change but really it means postpone the change until the next reboot. This is a bit like buying something on mail order. You can pay for it now but you won't get it until the LPAR gets bounced.

chdev -l hdisk0 -a hcheck_interval=60 -P

Option 2: just do it

With this option you bring down the volume group (varyoffvg), change the setting and activate the volume group again (varyonvg). Here are the steps:

unmount file systems after stopping any processes using them
deactivate any paging spaces in that volume group (swapoff or just use SMIT)
deactivate the volume group using varyoffvg
then run the chdev command without the -P flag.

chdev -l hdisk0 -a hcheck_interval=60

activate the volume group using varyonvg
mount the file systems, reactivate paging space if applicable.

As you can't varyoff a rootvg volume group while it's in use, this option only works for non-rootvg volume groups, and of them, only the ones that you can really vary off.

Option 3: prevention is better than cure

If you think ahead of time, you can change the health check interval before you add the disk to a volume group.

IBM has a very good step-by-step explanation of implementing MPIO. It mentions the need for setting the reserve_policy to no_reserve, and gives some other helpful hints. Although it does say you have to do a reboot of the LPAR, that's probably because it assumes you're setting this up for a rootvg disk.

Update: Watch out for that little man

If you think I'm joking about a little man inside your server, here's a little experiment. Next time you stick an insensitive "LEGACY" label on a computer and announce to the world that it's getting retired after 15 years of outstanding service, see if that little man doesn't protest by breaking the computer just before it really is no longer needed, and just enough to remind you who's the boss.

Free coffee with every AIX 7 install

AnthonyEnglish Marcações: download entitled_software_support vios virtual_media vio aix beta vmlibrary open aix7 ess ‎ 11.350 Visualizações

THE COFFEE CUP HOLDER IN THE COOL ROOM

When I went to install the AIX 7 open beta, I used the VIO server virtual media library. Virtual. No need to burn DVDs to put in the coffee cup holder in the IBM machine in the cool room a.k.a. the data centre. Did it all remotely, even though the data centre was literally across the room.

After stepping through the SMS menus and pressing enter to continue the mksysb restore, the install of AIX 7 took 7 minutes, which was

just enough time for a coffee!

I wonder whether AIX 8 will take 8 minutes.

At the end of the install, I got the message:

Please remove the mksysb media from the drive, insert the product media and press the ENTER key.

At this point, with real media, you would eject the mksysb DVD (or CD) from the coffee cup holder and insert the AIX installation DVD (or CD) number 1. But since I kept the data centre door safely closed, with me on the outside, I did it all from the VIO server command line. On recent releases of the HMC you can do it using the GUI - Virtual Storage Management, but the VIOS command line is easy and fast.

I unloaded the AIX 7 open beta ISO image from my sandbox LPAR virtual optical device:

unloadopt -vtd sandbox_cd0

Load the (non-existent) product media

Then I had to load the product media. As I didn't have AIX 7 installation media - the beta only comes in a mksysb image - I used the DVD for AIX 6.1 which I had already downloaded from Entitled Software Support, as explained in this post on the AIXpert blog. I like to keep my AIX DVD ISO images permanently on the VIO server VMLibrary.

Here's how I loaded the AIX 6.1 media:

loadopt -vtd sandbox_cd0 -disk aix_6100-05_1_of_2.iso

I then returned to the LPAR console and pressed ENTER to continue.

Cleaning up

The install continued without any issues and the I had just enough time to wash up my coffee cup before the LPAR rebooted. Couldn't have had the coffee inside a data centre, and I wouldn't have had anywhere to put my coffee cup anyway.

As for using AIX 6.1 media for an AIX 7 mksysb, I've posted a question about it on the AIX 7 Open Beta forum.

"So where's my free coffee?"

This is a virtual world, pal. Did you expect me to post you a cup of coffee from the antipodes? What this post does give you is the

opportunity

to have a coffee while you install AIX 7. Now if you'd used the physical media, you wouldn't be able to do that, would you?

It's about time: set up NTP on the VIO server

AnthonyEnglish Marcações: hmc vio_server time_synchronisation vios ntp aix xntpd ‎ 4 Comentários ‎ 27.103 Visualizações

MANAGING YOUR TIME

When it comes to diagnosing error reports, being able to check the sequence of events is essential. That's very hard to do if the servers reporting the errors don't have matching time. In his storage blog the other Anthony Down Under gave this advice: Changing times call for NTP. (In case you're wondering, there are people working in the IBM space Down Under who are not called Anthony).

So following AnthonyV's call to action, I'm going to show you how easy it is to set up NTP on the VIO server.

You can set up the NTP client on the VIOS in three steps:

vi /home/padmin/config/ntp.conf
startnetsvc xntpd
ln -sf /home/padmin/config/ntp.conf /etc/ntp.conf

These three steps are taken from the PowerVM Virtualization Managing and Monitoring Redook.Chapter 4, section 4.3.

Optional step 4 is to set the date and time using the VIO Server chdate command.

Have you got the time?

If you've got the time, here are those three steps in a little more detail.

Step 1 is to add your NTP server to the ntp configuration file. Note the location of this file: /home/padmin/config directory.

server ptbtime1.ptb.de

server ptbtime2.ptb.de

driftfile /home/padmin/config/ntp.drift

tracefile /home/padmin/config/ntp.trace

logfile /home/padmin/config/ntp.log

Step 2 actually starts the xntpd daemon. The VIO server startnetsvc command starts services such as telnet, ftpd and sshd when you're logged in as padmin. This command, along with startsvc performs a similar function to the AIX startsrc command. There are corresponding commands to stop these services: stopnetsvc / stopsvc.

Step 3: is explained by that Monitoring and Management Redbook:

In the Virtual I/O Server 1.5.1.1-FP-10.1 you need to restart the xntpd daemon using the stopnetsvc and startnetsvc commands after every reboot, otherwise it will use /etc/ntp.conf as a configuration file instead of /home/padmin/config/ntp.conf. As a workaround you can set up a symbolic link from /home/padmin/config/ntp.conf to /etc/ntp.conf.

As far as I'm aware, this hasn't changed in more recent versions of the VIO server, although since APAR IZ13781 you can specify an alternate ntp.conf file in /etc/rc.tcpip.

Out of time?

If you've been following this blog and faithfully carrying out its recommendations every morning (well, apart from the flippant ones which occasionally slip in), you will have already learned how to set the time on your HMC. Now you can add the VIO server to your list, so that if the world gets hit by an asteroid, you'll know exactly what time it happened. That will be helpful for when you log a support call.

Feed para Entradas de Blog

Blogs

AIX Down Under

▼ Marcações

▼ Blogs Semelhantes

Chris's AIX B...

Asset Managem...

Application P...

Application I...

AIXpert Blog

▼ Blogs de Ideias Semelhantes

IBM PureData-...

IBM Forms Exp...

Rational Soft...

IBM Tunisia H...

主机知刊

▼ Archive

▼ Links

▼ Autores do Blog

AIX Down Under

UPDATED: Migration to AIX 7.1 in 35 minutes

UPDATED: AIX 7 features for AIX 6

DR across the drink - virtualisation helps earthquake victims

Is your AIX system clocking up overtime?

Geek Trivial Pursuit: one-character commands

The AIX LVM - a perfect gentleman

From Breakfast to Bridge to Empire

UPDATED: MPIO Health Check? Wait a minute!

Free coffee with every AIX 7 install

It's about time: set up NTP on the VIO server