Hello, Experts. I''ve got a problem. I''m trying to expand my main zpool (rpool), but don''t know how to do that. (i''m 100% newbie in non-windows world) I use Osol under Vmware on Windows. I had a pretty small vhdd -> only 12gb. Yesterday i decided to expand my virtual drive to 20gb. (After several tries to upgrade the OS to a newest dev-releases and installing some software, I had only ~ 4.8 GB free space with only one boot-environment) So, the expansion of the vhdd was done with vmwarevdiskmanager in a minute. My vhdd is now about 20gb, but osol didn''t see , that the capacity of the disk was increased. How do i make new unallocated free-space on my vhdd visible/usable for osol ?! I''ve olready tried to do: zpool add -f rpool c8t0d0 but get an error: invalid vdev specification the following errors must be manually repaired: /dev/dsk/c8t0d0s0 is part of active ZFS pool rpool. Please see zpool(1M). I attach some logs (zfs list, zpool list and zpool status -v) So. What should I do first? P.S. Sorry for my English. -- This message posted from opensolaris.org -------------- next part -------------- A non-text attachment was scrubbed... Name: zfs.list.log Type: application/octet-stream Size: 485 bytes Desc: not available URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20100301/a9fcf780/attachment.obj> -------------- next part -------------- A non-text attachment was scrubbed... Name: zpool.list.log Type: application/octet-stream Size: 96 bytes Desc: not available URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20100301/a9fcf780/attachment-0001.obj> -------------- next part -------------- A non-text attachment was scrubbed... Name: zpool.status.log Type: application/octet-stream Size: 3036 bytes Desc: not available URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20100301/a9fcf780/attachment-0002.obj>
Vladimir Leitenberger wrote:> Hello, Experts. > I''ve got a problem. I''m trying to expand my main zpool (rpool), but don''t know how to do that. (i''m 100% newbie in non-windows world) > > I use Osol under Vmware on Windows. > I had a pretty small vhdd -> only 12gb. Yesterday i decided to expand my virtual drive to 20gb. (After several tries to upgrade the OS to a newest dev-releases and installing some software, I had only ~ 4.8 GB free space with only one boot-environment) > > So, the expansion of the vhdd was done with vmwarevdiskmanager in a minute. My vhdd is now about 20gb, but osol didn''t see , that the capacity of the disk was increased. > > How do i make new unallocated free-space on my vhdd visible/usable for osol ?! > > I''ve olready tried to do: > > zpool add -f rpool c8t0d0 > > but get an error: > > invalid vdev specification > the following errors must be manually repaired: > /dev/dsk/c8t0d0s0 is part of active ZFS pool rpool. Please see zpool(1M). > > I attach some logs (zfs list, zpool list and zpool status -v) > > So. What should I do first? > > P.S. Sorry for my English. >I''m assuming you are using a newer development release (build 117 or later) You need to set the autoexpand property on your root pool: # zpool set autoexpand=on rpool More info here: http://docs.sun.com/app/docs/doc/817-2271/githb?a=view You may need to stop and start the OpenSolaris VM afterwards. -- Erik Trimble Java System Support Mailstop: usca22-123 Phone: x17195 Santa Clara, CA
Hello Erik, first of all, thanks for quick replay. About using later builds: Right now I''m using a snv_111b bild (osol2009.06 - 5.11 snv_111b i86pc i386 i86pc Solaris). As i already said, I tried to upgrade to a newest dev-release but I wasn''t lucky with that (panic at the boot, crushes, etc), so i staid by the osol_111b. I tried your suggestion, but no results. There''s no property ''autoexpand'' for my rpool. I tried "zpool get all rpool" and this property wasn''t listed. I also tried "zpool online -e rpool c8t0d0s0" but get an error(invalid option ''e'') again. I, also, scrubbed my rpool. I attach you another "zpool status -v rpool" log-file -- This message posted from opensolaris.org -------------- next part -------------- A non-text attachment was scrubbed... Name: zpool-status-rpool-v-scrubbed.log Type: application/octet-stream Size: 12506 bytes Desc: not available URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20100302/153db481/attachment.obj>
For rpool, which has SMI labels and fdisk partitions, you need to expand the size of those, and then ZFS will notice (with or withhout autoexpand, depending on version). -- Dan. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20100302/324a5176/attachment.bin>
How can I do that ? -- This message posted from opensolaris.org
Daniel Carosone wrote:> For rpool, which has SMI labels and fdisk partitions, you need to > expand the size of those, and then ZFS will notice (with or withhout > autoexpand, depending on version). > > -- > Dan.I don''t believe that is true for VM installations like Vladimir''s, though I certainly could be wrong. It would be entirely dependent on how the initial installation was done, as to whether an SMI/fdisk setup was in use. That all said, with Vladimir on 111b (which is before the autoexpand property was implemented, and the usual ''zpool import/export'' isn''t trivial on the rpool), and the fact that he''s getting a bunch of reported errors on the virtual disk (as reported by zpool status), I would just not bother at this point. Vladimir - I would say your best option is to simply back up your data from the OpenSolaris VM, and do a fresh re-install using the larger Virtual Disk size. You can then upgrade to the later Dev builds cleanly. If you are having problems with this, let us know, because this should be rather straightforward. -- Erik Trimble Java System Support Mailstop: usca22-123 Phone: x17195 Santa Clara, CA
On Tue, Mar 02, 2010 at 02:04:52PM -0800, Erik Trimble wrote:> I don''t believe that is true for VM installations like Vladimir''s, > though I certainly could be wrong.I think you are :-)> Vladimir - I would say your best option is to simply back up your data > from the OpenSolaris VM, and do a fresh re-install using the larger > Virtual Disk size. You can then upgrade to the later Dev builds > cleanly. If you are having problems with this, let us know, because > this should be rather straightforward.You could also attach a second virtual disk of a larger size as a mirror, resilver, and detach the original. You will still need to put fdisk and SMI labels on that new disk. I suggest reading the ZFS Best Practices page, the section on root pool recovery and other manipulations in particular, for detailed instructions. -- Dan. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20100303/67b20924/attachment.bin>
Daniel Carosone wrote:> On Tue, Mar 02, 2010 at 02:04:52PM -0800, Erik Trimble wrote: > >> I don''t believe that is true for VM installations like Vladimir''s, >> though I certainly could be wrong. >> > > I think you are :-) > >And you would be correct. No booting from EFI labeled disks for now, and SMI/VTOC-labeled disks require an fdisk partition for the rpool (though, not for other pools). One must resize the SMI label for the rpool to recognize the new underlying disk size. Yet another reason to get the EFI support faster. :-)>> Vladimir - I would say your best option is to simply back up your data >> from the OpenSolaris VM, and do a fresh re-install using the larger >> Virtual Disk size. You can then upgrade to the later Dev builds >> cleanly. If you are having problems with this, let us know, because >> this should be rather straightforward. >> > > You could also attach a second virtual disk of a larger size as a > mirror, resilver, and detach the original. You will still need to put > fdisk and SMI labels on that new disk. > > I suggest reading the ZFS Best Practices page, the section on root > pool recovery and other manipulations in particular, for detailed > instructions. > > -- > Dan. >While that''s instructive, if Vladimir has no real attachment to his current install, frankly, it''s going to be a while lot faster just to Nuke It From Orbit, and redo the install (especially for a newbie that Vladimir has stated he is). -- Erik Trimble Java System Support Mailstop: usca22-123 Phone: x17195 Santa Clara, CA
Hmm is it pissoble to upgrade my current zfs version to the new one, without updating whole system (pkg image-update)? The Problem is, i''ve made 5.1 Gb free space and tried to make a normal update, but upgrading from 111b to current 133 is a huge jump. 1050 Mb must be downloaded and the installation needs much more. 5.1gb freespace isn''t enough for that ... (P.S. I know it''s a offtopic, but could some one explain me, why osol needs so much space on the plate? I mean, i''ve got 12 gb vhhd and only 5 is free. I need more that 6 gb freespace to make an update. Is this normal for osol ?!) -- This message posted from opensolaris.org
On Wed, 2010-03-03 at 06:59 -0800, Vladimir Leitenberger wrote:> Hmm is it pissoble to upgrade my current zfs version to the new one, without updating whole system (pkg image-update)? > > The Problem is, i''ve made 5.1 Gb free space and tried to make a normal update, but upgrading from 111b to current 133 is a huge jump. 1050 Mb must be downloaded and the installation needs much more. 5.1gb freespace isn''t enough for that ... >You want to go over to the install-discuss list. It''s entirely possible to upgrade to any intermediary build - you don''t have to just go all the way up to the current one. You might be able to do the jump to b133 in 2 or 3 intermediary steps, cleaning out after each one. That said, there is a lot of stuff being cached locally, so you can clean it out between upgrades. /var/pkg is particularly susceptible to ballooning.> (P.S. I know it''s a offtopic, but could some one explain me, why osol needs so much space on the plate? I mean, i''ve got 12 gb vhhd and only 5 is free. I need more that 6 gb freespace to make an update. Is this normal for osol ?!)It doesn''t, really - you need ~6GB for a typical fresh install plus goodies (+ swap + dump); 3GB seems to be about the minimum install these days, which is slightly larger than Ubuntu Desktop. You tend to accumulate more space in upgrades (many people forget to remove old snapshots when finished), and the download process can eat up a variable amount of space (up to your current size). Here''s the worst-case example: B111 root = 10GB files needed to upgrade to B133 = 5GB = total start size of 15GB upgrade process: (1) snapshot and create B133 boot filesystem = 0GB more (2) upgrade the B133 filesystem = 5GB more used (20GB now in use) (3) boot to the new B133 filesystem = 0GB more used. (4) delete the upgrade packages in the B133 filesystem = NO SPACE FREED (files still exist in B111 snapshot) (5) delete b111 snapshot = 10GB freed So, fully upgrade a 10GB file system, you would temporarily need 10GB more. This is fairly typical of most other UNIX/Linux systems in terms of temporary space requirements. Just with Linux, you often forget about it because the "temp" space is actually on CD or NFS directory (though, not always). Try watching your disk space during an ''apt-get dist-upgrade'' on Ubuntu or Debian, and you''ll see an identical issue. -- Erik Trimble Java System Support Mailstop: usca22-123 Phone: x17195 Santa Clara, CA Timezone: US/Pacific (GMT-0800)
It''s a litle while ago, but i''ve found a <a href="http://www.youtube.com/watch?v=tpzsSptzmyA">pretty helpful video on YT</a> how to completely "migrate" from one harddrive to another. -- This message posted from opensolaris.org
Yes, it is helpful in that it reviews all the steps needed to get the replacement disk labeled properly for a root pool and is identical to what we provide in the ZFS docs. The part that is not quite accurate is the reasons for having to relabel the replacement disk with the format utility. If the replacement disk had an identical slice 0 (same size or greater) with an SMI label then no need exists to relabel the disk. In this case, he could have just attached the replacement disk, installed the boot blocks, tested booting from the replacement disk, and detached the older disk. If replacement disk had an EFI label or no slice 0, or a slice 0 that is too small, then yes, you have to perform the format steps as described in this video. Thanks, Cindy On 04/26/10 08:24, Vladimir L. wrote:> It''s a litle while ago, but i''ve found a <a href="http://www.youtube.com/watch?v=tpzsSptzmyA">pretty helpful video on YT</a> how to completely "migrate" from one harddrive to another.