Search results for query: *

Probably easier to allocate another LUN to the VG, migrate and remove the original LUN

How much more space are you trying to give it? If you are trying to increase it by 68GB it will probably fail - try a lower number.

Can you not add the disk into the same VG and use migratepv?

Speed/duplex set correctly? bootp can be a bit fussy about that......

What does 'last reboot' say?

You also have to take into account that you are restricted to what you can dynamically assign by the 'maximum' values for cpu/memory you have set in the profile.

If you dynamically assign it, you don't need to reboot. However if you want it to be permanent you will need to change the profile for that lpar, shut it down and then activate it from the HMC - a reboot will not activate the new profile, it has to be shutdown and then activated.

I've used this method with SAN disks (but not rootvg), the problem is you have to varyoff/on the VG. How about assigning bigger SAN disks to rootvg then migratepv old to new, then remove old?

I'm using the following to backup a directory" ^ There, you've just said it, use the backup command :) find /dir/to/backup|backup -ivqf /dirtobackupto/filename.bak restore -xdqvf /dirtobackupto/filename.bak would restore it back exactly as it was.

Double check the zoning - make sure you have the WWPN's/aliases for the tape device and the fibre channel card for that server in the same zone.

I have recently migrated LPAR's from Power5 (dedicated resources) to Power6 (VIOS clients) using mksysb with no problems. The only difference to your scenario was that the LPAR's were upgraded to AIX 6.1 beforehand - this was because we are using TSM and the IBM TSM support team only support...

What is the output of instfix -icqk 5300-07_AIX_ML | grep :-: ??

There is only one way I know to get it 'back to normal': Run multibos -R to remove standby LV's (multibos -Rp to preview). If it removes the normal hd5 etc (and leaves bos_hd5) you will need to run multibos again: multibos -sX (sXp to preview) set bootlist to the new hd5, reboot, and then...

You need to make sure you only have hd5 as the boot logical volume on your root disk. For instance if you had previously used multibos and had hd5 and bos_hd5, alt disk would fail on that as it's hard coded to only use hd5 (and cannot rename bos_hd5), cleaning up multibos to leave just hd5...

Thanks sbix I have written a script now to get it from the unique_id - the problem was the LUN ID would appear differently depending on whether it was ESS or DS. The storage unit identifer appears in the unique_id field as well, so my script looks for that and does one thing for ESS and...

I set up my mpio disks with algorithm - round_robin reserve_policy-no_reserve I guess this is correct, I had not even looked into MPIO until last week! I have now written a script to find the LUN numbers as well. @p5wizard - we could have just kept our DS boxes on sdd, but the decision was...

I looked at SDDPCM, according to IBM only the native MPIO works with XIV right now, I'm sure that will change as XIV becomes more 'standard'

Thanks, I can see the LUN can be identified by that as well - still not as clear as the lsvpcfg command though!! ESS looks easy enough, I have seperated the LUN ID with a * U787A.001.DPM035R-P1-C3-T1-W5005076300CCABF2L5*00D*000000000000 MPIO Other FC SCSI Disk Drive (00D) DS is...

We are in the process of moving from SDD to MPIO to prepare for new XIV storage (we currently have ESS and DS8000). With SDD we could query the vpaths for the LUN using lsvpcfg|grep vpathx Using standard MPIO on AIX 5.3.8 the best I have found so far is getting it from the unique_id field...

That was actually the first thing I tried, but it didn't work as I was testing it by switching user from root to the user I wanted logged out - obviously logging in directly as this user and then exiting does work :) Was just having my stupid head on for a little while there! Thanks for your...