On 10/19/10 9:32 AM, Joe Balenzano wrote:
Alexandre Chartre wrote:
- He could of simply just unbound the ldom, grow the disk image file, then bind
the the ldom.
Nno need to remove and add it back? If he had done this, his partition table
would not have
changed (other than the size of slice 2 with S10 U8+ or withn patch 139562-02 )
In that case, the partition table would not have changed at all, and that's
currently
a problem because there's currently no easy way to adjust an existing partition
table
to a new disk size (other than some format(1m) tricks).
I was under the impression that 139562-02 changed the vio driver to deal with
this? What are the
tricks you have to perform to get this to work?
139562-02 is required but not enough. 139562-02 allows the guest domain to
automatically
see the new vdisk size. However this does not change the partition table (which
is
stored on the vdisk).
The second step is to adjust the partition table so that it matches with the
new disk
size. The way you do that depends on the disk label type (VTOC or EFI); and
it's easier
if you have Solaris Nevada and a EFI label. See the attached email for details.
alex.
--- Begin Message ---
It is working as expected, i.e. the size of the virtual disk
will be increased (and you don't need to reboot any domain).
However when you change the size of the volume, this going to
effectively increase the size of the virtual disk but the disk
label and partitions will be unchanged.
See the following CRs:
6241086 Format should allow label adjustment when disk/lun size changes
6725986 format(1m) "expand" command should also work with VTOC label
Here is a way to adjust the disk label:
- first use prtvtoc to backup the current disk label so that
it can be restored using fmthard in case something goes wrong
during this procedure:
# prtvtoc /dev/rdsk/c0dXs2 > label.c0dX
- run "format" -> "verify" and save this output
- if the virtual disk has a EFI label (i.e. it appears with a
description like "<Unknown-Unknown-0001-15.00GB>") then do this:
(see also the attached mail for an example):
. run "format" -> "type" -> "0. other"
. the command will ask to "Enter maximum number of LBAs:"
. enter the number indicated after "sectors =" in the previous
"format" -> "verify" output
. run "format" -> "partition" and re-create the partitions
from the previous "format" -> "verify" output. The partition
should start at the same sector but you can extend it using
the new sectors available.
- if the virtual disk has VTOC label then do:
. change the disk label to an EFI label:
use "format -e" then "label" and select EFI label
. change the disk label back to a VTOC label:
use "format -e" then "label" and select VTOC label
Now you need to recreate the initial partitions. To do that you first
need to check that the cylinder size of the disk geometry hasn't changed.
If it has changed then you will be unable to recreate the initial partitions.
. run "format" -> "verify" and check that "nhead" and "nsect" are the same
as before the geometry was changed (from the "format" -> "verify" output
that was initially saved)
. recreate all partitions (except slice 2) from the initial "format" ->
"verify"
output. Do not change slice 2.
You are done. If you have a single slice (e.g. s0) then you can extend that
slice by changing its size (but do not change the starting cylinder).
alex.
On 09/01/09 15:05, Ann Kucharski wrote:
Why doesn't this work for my customer?
Patched the client LDOM to the same level ( 141414-07 )
Still see the same behavior
- Primary> stop testldom
- Primary> add 5Gb metadevice with vdsdev/vdisk
- Primary> start testldom
- Guest> devfsadm -Cv ; format - see new volume at 5Gb
- Primary> add another 5Gb to metadevice
- Guest> devfsadm -Cv ; format - still see new volume at 5Gb
- Guest> reboot -- -rv
- Guest> devfsadm -Cv ; format - still see new volume at 5Gb
- Guest> init 0
- Primary> ldm stop-domain ldomtest ; ldm start-domain ldomtest
- GuestOK> boot -rv
- Guest> devfsadm -Cv ; format - still see new volume at 5Gb
--- End Message ---
_______________________________________________
ldoms-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/ldoms-discuss
