idisk, partition tables and so on ...

[Eric SAUBIGNAC]

Bonjour,

For some reasons (too long to explain there) I need to reduce by 16 Mo the size of a DD that supports vg00 on an Itanium box, 11iv2.

Note : I did the test on an HPVM virtual machine, but I guess the problem would be the same on a real box

Thanks in advance

Eric

When I try to boot in maintenance mode (-lm) the reduced disk, the system panics :-((( Here is the error message :


------------------------------------------------------------------------


Boot device's HP-UX HW path is: 0/2/0/0.0.0
iether0: INITIALIZING HP PCI/PCI-X 1000Base-T at hardware path 0/0/0/0
iether1: INITIALIZING HP PCI/PCI-X 1000Base-T at hardware path 0/0/1/0

System Console is on the Built-In Serial Interface
read_efi_hdr: physio failed
WARNING: Open failed on device 0x1f020002 (error 0x5).
WARNING: Can not read LVM BOOT information (lvmrec).
read_efi_hdr: physio failed
read_efi_hdr: physio failed
WARNING: Open failed on device 0x1f020002 (error 0x5).
WARNING: Can not read LVM BOOT information (lvmrec).
read_efi_hdr: physio failed
WARNING: Open failed on device 0x1f020002 (error 0x5).
WARNING: Can not read LVM BOOT information (BDRA).
read_efi_hdr: physio failed
WARNING: SWAP device 0xfffffffe is a non-LVM partition, disallowed on LVM disk.
WARNING: SWAP device 0xfffffffe has been deconfigured (set to 0xffffffff).
WARNING: Logical volume for Dump expected but not found.
Swap device table: (start & size given in 512-byte blocks)
WARNING: no swap device configured, so dump cannot be defaulted to primary swap.
WARNING: No dump devices are configured. Dump is disabled.
read_efi_hdr: physio failed
mountfs:opend
read_efi_hdr: physio failed

System Panic:

panic: all VFS_MOUNTROOTs failed: NEED DRIVERS ?????
Stack Trace:
IP Function Name
0xe000000000fc88e0 vfs_mountroot+0x1d0
0xe000000001302040 im_mountroot+0x60
0xe000000001784b50 DoCalllist+0x3a0
End of Stack Trace

linkstamp: Tue Dec 08 19:33:12 MET 2009
_release_version: @(#) $Revision: vmunix: B11.23_LR FLAVOR=perf Fri Aug 29 22:35:38 PDT 2003 $

------------------------------------------------------------------------


I am a bit surprised : the size has been reduced by 16 Mo from the end of the disk. So, what I have broken or corrupted is supposed to be the 3rd HPSP partition. Even if the 2nd partition (vgOO) has been reduced, it is from the end, not from the beginning, so why this message "Can not read LVM BOOT information" ? And why can't I boot in maintenance mode ?


What I suspect, is a problem with partition tables ... Under a recovery shell, idisk finds no valid partition :

------------------------------------------------------------------------
# idisk -r /dev/rdsk/c1t0d0
idisk version: 1.32
********************** WARNING ***********************
If you continue you may destroy all data on this disk.
Do you wish to continue(yes/no)? yes
idisk: Both the primary and alternate partition table entries are bad.
Restoration is not possible. Partitions must be created using data file.
------------------------------------------------------------------------


So finally, the question is : is there a way to recreate partition tables without erasing data that is still valid ?

[Torsten.]

Eric,

"reduce by 16 Mo" - what does this mean?


The last block on the disk holds the alternate EFI partition table - no idea what happens if this is lost.

[Eric SAUBIGNAC]

Hi Torsten,

>>> "reduce by 16 Mo" - what does this mean?

16 Mo = 4 x 4 PE of 4 Mo

I fact I am migrating an HPVM landscape from 11iv2 Host / HPVM 3.0 to 11iv3 Host / HPVM 4.1.

All VM, are configured with backing storage as LV : client needs mirroring.

Some VM are now migrated in the new host. No problem for this part : LV have been imported in the new host, VM definition created, VM started and updated, etc ...

What I would like now, is to take advantage of the new LVM 2.x capabilities at the host level ...

Well, vg00 in each VM is installed on a virtual LVDisk which is a mirrored LV that use all PE of a LVM 1.0 dedicated VG on the host (for exemple vgMyVM_os)

When I try vgversion on the vgMyVM_os it tells me to free some extends from the end of the disk or to add space. Normal.

I could add space, but it will be 1 Go at once (EVA Storage). I would prefer the reduce method.

And because vg00 in the VM has many free extends at the end I thought I will be able to do that. My idea was : stop the VM, lvreduce the LV at host Level, boot the VM in maintenance mode, apply vgmodify to validate the reduced size, if necessary import vg00, ....

But I totally forgot that there are some partition tables on an EFI system disk ...

>>> The last block on the disk holds the alternate EFI partition table - no idea what happens if this is lost

I guess I have lost the alternate partition, and seriously damaged the 3rd HPSP one. I never thought that it could give such a bad result :-(((

Any idea on how to recover from this situation ?

Eric

[Torsten.]

Still not sure what "Mo" is - Megabyte?


However, if you reduce the LV at VMHost level, the guest has no clue what happens.

I still not get the reason why you need to reduce anything at all.

Can you boot the guest into maintenance mode?

[Eric SAUBIGNAC]

>>> Still not sure what "Mo" is - Megabyte?

Yes, Mega Octet

>>> However, if you reduce the LV at VMHost level, the guest has no clue what happens.

Sure. But guest is stopped when the LV is reduced and my plan was to apply "vgmodify" in maintenance mode to validate size contraction.

>>> I still not get the reason why you need to reduce anything at all

migrate LV on the host from LVM 1.0 to 2.1.

>>> Can you boot the guest into maintenance mode?

no. panic. See my first post.

PS : Is my english so bad ... lol ... ;-) ?

Eric

[Torsten.]

The migration from LVM 1.0 to 2.x requires a LVOL reduce???


Your english isn't bad at all ... maybe I just need some coffee.

[Eric SAUBIGNAC]

Here is output from "vgversion" on the host :

----------------------------------------------------

root@lur:/#vgversion -V 2.1 -r -v vgeredu_os
The space required for Volume Group version 2.1 metadata on Physical Volume
/dev/disk/disk535 is 12224 KB, but available free space is 9472 KB.
0 free user extents from the end of the Physical Volume /dev/disk/disk535
will be utilized to accommodate the Volume Group version 2.1 metadata.
vgversion: More space for metadata is required. Take one of the following
actions:
1. Free 1 extents more from the end of the Physical Volume
2. Increase the disk size by 2752 KB to avoid using the free user extents
3. Increase the disk size by 2752 KB and use the free user extents

----------------------------------------------------

That's why I am trying to reduce the LV : it takes all PE in the VG

[Torsten.]

The system suggest to increase the PVOL, but you decide to reduce the LVOL, right?

Question is, what (how much) is missing now?

See

http://docs.hp.com/en/B2355-90950/img/gfx42.gif

All LVM related data is in the beginning of partition 2.

I assume the secondary EFI tables are lost now.
Looks like EFI cannot accept this.

[Eric SAUBIGNAC]

>>> The system suggest to increase the PVOL

Yes, but storages are EVA. So I can't add less than 1 GB to a given vDisk. We have 12 VMs, and a bit more than 100 vDisk to handle software and databases (I also plan to migrate them to LVM2.1). If I follow this way we will need more than 100 GB to achieve the migration. And the client is a little bit poor with free space.

>>> http://docs.hp.com/en/B2355-90950/img/gfx42.gif

That is exactly how I understand the layout.

>>> All LVM related data is in the beginning of partition 2.

Yep. So as you said "Question is, what (how much) is missing now?"

>>> I assume the secondary EFI tables are lost now

... and probably the end of 3rd partition. Anyway, the VM is completly crashed at this time : I have tried a "idisk" command under recovery shell :-(((( Almost reinstalled now from an ignite image. I will lvsplit the LV before next tests ;-)

But, I would like to understand, HOW this f.....g system can get corrupted by reducing the size. In theory, LVM related data is at the beginning of partition 2 and has not been impacted ???!!! At least I should be able to boot in maintenance mode ...

I guess it means that doing the same test with a physical host booting on SAN and reducing the size of the system disk would gave the same result. But I have no system to play with :-(

Hope I will have less trouble when migrating datas ...

[Torsten.]

How large are your PEs?

Since partiton 3 is usually 400MB, partition 2 should be unchanged.

So the problem must be with the EFI structure.

Can you get an EFI shell?

(it's possible for a guest, isn't it?)




Regarding idisk:

Restore the EFI partition headers and tables. This option checks both the primary header and tables and the alternate header and tables. If one is found bad it is restored from the other good version. One of either the primary or alternate header and tables must be good for this option to succeed. The -w option must be specified for information to be written to the disk.



Note "-w"!

Not sure if this helps, since idisk complains about both copies are bad ... :-(