Xen users - Jun 2008 - what''s correct way of shrinking LVM based domU?

Hi all

I want to shrink one of my LVM based domU''s, but don''t quite
know how to
do it.

I have searched the Wiki  & HOWTO''s, and they all show you how
expand /
enlarge a LVM based domU, but not shrinking it.

So, I stopped (destroyed) the domU, and then resized it as follows: 
lvresize /dev/data/cpanel1 -L10GB (It was 100GB), but when I a started 
it up again, I got some errors about the the disk being corrupt, and 
then a kernel panic.

So, how should I shrink a LVM based domU?

-- 

Kind Regards
Rudi Ahlers
CEO, SoftDux

Web:   http://www.SoftDux.com
Check out my technical blog, http://blog.softdux.com for Linux or other
technical stuff, or visit http://www.WebHostingTalk.co.za for Web Hosting stuff


_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

Rudi Ahlers wrote:
> Hi all
>
> I want to shrink one of my LVM based domU''s, but don''t
quite know how
> to do it.
>
> I have searched the Wiki  & HOWTO''s, and they all show you how
expand
> / enlarge a LVM based domU, but not shrinking it.
>
It''s the opposite, literally, of growing.
> So, I stopped (destroyed) the domU, and then resized it as follows: 
> lvresize /dev/data/cpanel1 -L10GB (It was 100GB), but when I a started 
> it up again, I got some errors about the the disk being corrupt, and 
> then a kernel panic.
>
Looks like you missed out a vital step: you shrunk the logical volume 
without first shrinking the file system within it.  Note that while you 
can often grow a file system while it is on-line you almost always need 
the file system off-line in order to shrink it.

In this case, you need to shrink the file system, logical volume (if 
any), physical volume (if any) and partition in the guest OS _before_ 
you shrink the logical volume that contains them all in dom0.  Of 
course, you can do all this from dom0 because the file system(s) contain 
in the logical volume are all off-line.

jch

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

John Haxby wrote:
> Rudi Ahlers wrote:
>> Hi all
>>
>> I want to shrink one of my LVM based domU''s, but
don''t quite know how
>> to do it.
>>
>> I have searched the Wiki  & HOWTO''s, and they all show you
how expand
>> / enlarge a LVM based domU, but not shrinking it.
>>
> It''s the opposite, literally, of growing.
>> So, I stopped (destroyed) the domU, and then resized it as follows: 
>> lvresize /dev/data/cpanel1 -L10GB (It was 100GB), but when I a 
>> started it up again, I got some errors about the the disk being 
>> corrupt, and then a kernel panic.
>>
> Looks like you missed out a vital step: you shrunk the logical volume 
> without first shrinking the file system within it.  Note that while 
> you can often grow a file system while it is on-line you almost always 
> need the file system off-line in order to shrink it.
>
> In this case, you need to shrink the file system, logical volume (if 
> any), physical volume (if any) and partition in the guest OS _before_ 
> you shrink the logical volume that contains them all in dom0.  Of 
> course, you can do all this from dom0 because the file system(s) 
> contain in the logical volume are all off-line.
>
> jch
>
ok, I don''t know LVM at all. This is all a trail and error thing, since
my previous installations have been image based and is difficult to resize.

So, what you''re saying is that I should do this from the domU itself? 
But that then means it need to be running?

This is what I have:

[root@cPanel002 ~]# [root@HF-LINSRV01 ~]# lvscan
  ACTIVE            ''/dev/data/cpanel002'' [100.00 GB] inherit
  ACTIVE            ''/dev/data/windows2003_web'' [30.00 GB]
inherit
  ACTIVE            ''/dev/data/storage'' [50.00 GB] inherit
  ACTIVE            ''/dev/data/cacti'' [20.00 GB] inherit
  ACTIVE            ''/dev/data/cpanel2'' [30.00 GB] inherit
  ACTIVE            ''/dev/system/root'' [39.06 GB] inherit
  ACTIVE            ''/dev/system/swap'' [9.75 GB] inherit


I need to resize the 100GB /dev/data/cpanel002

Do I enter the domU, and then resize it''s partition first?

[root@HF-LINSRV01 ~]# xm console cPanel002
lvscan
  ACTIVE            ''/dev/VolGroup00/LogVol00'' [95.59 GB]
inherit
  ACTIVE            ''/dev/VolGroup00/LogVol01'' [1.94 GB]
inherit


Does this look right?

[root@cPanel002 ~]# lvresize /dev/VolGroup00/LogVol00  -L -80GB
  WARNING: Reducing active and open logical volume to 15.59 GB
  THIS MAY DESTROY YOUR DATA (filesystem etc.)
Do you really want to reduce LogVol00? [y/n]:

I somehow don''t trust this....



-- 

Kind Regards
Rudi Ahlers
CEO, SoftDux

Web:   http://www.SoftDux.com
Check out my technical blog, http://blog.softdux.com for Linux or other
technical stuff, or visit http://www.WebHostingTalk.co.za for Web Hosting stuff


_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

Rudi Ahlers wrote:
> ok, I don''t know LVM at all. This is all a trail and error thing, 
> since my previous installations have been image based and is difficult 
> to resize.
>
LVM isn''t your problem :-)   Imagine you''re shrinking the
physical disk
in a real machine.  You need to make the file system and whatnot in the 
real machine fit the new disk.
> So, what you''re saying is that I should do this from the domU
itself?
> But that then means it need to be running?
>
No, I''d be inclined to do all this from dom0 because you can handle all
the resizing stuff off-line.

If you do "fdisk /dev/data/cpanel1" you''ll see the disk
layout that your
guest OS sees.  You can also see them with "kpartx /dev/data/cpanel1" 
and kpartx''s "-a" switch will create entries in /dev/mapper. 
The man
page gives all the gory details.

Typically, kpartx will report two partitions -- the first, smaller one 
will be the guest''s /boot, the larger one will be the guests logical
volume.

So, and I haven''t actually tried all of this together, but I think it 
works.  So, make sure the domU is not running. "kpartx -va 
/dev/data/cpanel1" (or whatever) will create new entries in /dev/mapper 
for the disk image contained in that logical volume.  Now run "vgscan"
and that will look for any volume groups and, with any luck will find 
and activate VolGroup00 which contains the file system and swap 
partitions that the guest sees. 
>
> [root@HF-LINSRV01 ~]# xm console cPanel002
> lvscan
>  ACTIVE            ''/dev/VolGroup00/LogVol00'' [95.59 GB]
inherit
>  ACTIVE            ''/dev/VolGroup00/LogVol01'' [1.94 GB]
inherit
>
So this is what you''ll see in domU now.

At this stage, I''d be inclined to delete LogVol01 (which is almost 
certainly swap, but you should check) and then shrink the file system in 
LogVol00 with resize2fs.  Then shrink LogVol00 to snugly fit around the 
file system, then pvresize to shrink the physical volume and the 
lvcreate to re-create the swap partition.   So, broadly speaking, you 
want to resize the file system to, say, 8GB, shrink the physical volume 
to 10GB and then create a new 2GB logical volume for swap.  "vgdisplay 
-v /dev/VolGroup00" will tell you the name of the physical volume you 
want to shrink.   Now you can de-activate VolGroup00, run kpartx -vd to 
delete the entries in /dev/mapper and run fdisk on /dev/data/cpanel1 and 
shrink the partition that holds the physical volume.

Finally, and this is the last step, you can run lvresize 
/dev/data/cpanel1 to reduce the size of the logical volume in dom0.

What you were doing was hoping that shrinking /dev/data/cpanel1 would 
somehow shrink all of the data structures contained in that logical 
volume.  LVM, of course, neither knows nor cares what you actually store 
in a logical volume which is why it gives that warning message.

I generally over-shrink file systems and whatnot and then grow them to 
fill the available space once their container has been resized because 
that means I don''t need to worry about off-by-a-bit errors corrupting 
vital file systems.

Oh yes, back up anything important before you start :-)

Hope this helps.

jch

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

John Haxby wrote:
> Rudi Ahlers wrote:
>> ok, I don''t know LVM at all. This is all a trail and error
thing,
>> since my previous installations have been image based and is 
>> difficult to resize.
>>
> LVM isn''t your problem :-)   Imagine you''re shrinking the
physical
> disk in a real machine.  You need to make the file system and whatnot 
> in the real machine fit the new disk.
>
>> So, what you''re saying is that I should do this from the domU
itself?
>> But that then means it need to be running?
>>
> No, I''d be inclined to do all this from dom0 because you can
handle
> all the resizing stuff off-line.
>
> If you do "fdisk /dev/data/cpanel1" you''ll see the disk
layout that
> your guest OS sees.  You can also see them with "kpartx 
> /dev/data/cpanel1" and kpartx''s "-a" switch will
create entries in
> /dev/mapper.  The man page gives all the gory details.
>
> Typically, kpartx will report two partitions -- the first, smaller one 
> will be the guest''s /boot, the larger one will be the guests
logical
> volume.
>
> So, and I haven''t actually tried all of this together, but I think
it
> works.  So, make sure the domU is not running. "kpartx -va 
> /dev/data/cpanel1" (or whatever) will create new entries in 
> /dev/mapper for the disk image contained in that logical volume.  Now 
> run "vgscan" and that will look for any volume groups and, with
any
> luck will find and activate VolGroup00 which contains the file system 
> and swap partitions that the guest sees.
>>
>> [root@HF-LINSRV01 ~]# xm console cPanel002
>> lvscan
>>  ACTIVE            ''/dev/VolGroup00/LogVol00'' [95.59
GB] inherit
>>  ACTIVE            ''/dev/VolGroup00/LogVol01'' [1.94
GB] inherit
>>
> So this is what you''ll see in domU now.
>
> At this stage, I''d be inclined to delete LogVol01 (which is almost
> certainly swap, but you should check) and then shrink the file system 
> in LogVol00 with resize2fs.  Then shrink LogVol00 to snugly fit around 
> the file system, then pvresize to shrink the physical volume and the 
> lvcreate to re-create the swap partition.   So, broadly speaking, you 
> want to resize the file system to, say, 8GB, shrink the physical 
> volume to 10GB and then create a new 2GB logical volume for swap.  
> "vgdisplay -v /dev/VolGroup00" will tell you the name of the
physical
> volume you want to shrink.   Now you can de-activate VolGroup00, run 
> kpartx -vd to delete the entries in /dev/mapper and run fdisk on 
> /dev/data/cpanel1 and shrink the partition that holds the physical 
> volume.
>
> Finally, and this is the last step, you can run lvresize 
> /dev/data/cpanel1 to reduce the size of the logical volume in dom0.
>
> What you were doing was hoping that shrinking /dev/data/cpanel1 would 
> somehow shrink all of the data structures contained in that logical 
> volume.  LVM, of course, neither knows nor cares what you actually 
> store in a logical volume which is why it gives that warning message.
>
> I generally over-shrink file systems and whatnot and then grow them to 
> fill the available space once their container has been resized because 
> that means I don''t need to worry about off-by-a-bit errors
corrupting
> vital file systems.
>
> Oh yes, back up anything important before you start :-)
>
> Hope this helps.
>
> jch
>
Sorry John, but what you''re saying is very very confusing. I
don''t know
LVM at all, and what I''ve done is purely by chance, and using the 
defaults when installing CentOS.

-- 

Kind Regards
Rudi Ahlers
CEO, SoftDux

Web:   http://www.SoftDux.com
Check out my technical blog, http://blog.softdux.com for Linux or other
technical stuff, or visit http://www.WebHostingTalk.co.za for Web Hosting stuff


_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

Rudi Ahlers <Rudi@SoftDux.com> écrivait (wrote) :
> This is what I have:
>
> [root@cPanel002 ~]# [root@HF-LINSRV01 ~]# lvscan
>  ACTIVE            ''/dev/data/cpanel002'' [100.00 GB]
inherit
>  ACTIVE            ''/dev/data/windows2003_web'' [30.00 GB]
inherit
>  ACTIVE            ''/dev/data/storage'' [50.00 GB] inherit
>  ACTIVE            ''/dev/data/cacti'' [20.00 GB] inherit
>  ACTIVE            ''/dev/data/cpanel2'' [30.00 GB] inherit
>  ACTIVE            ''/dev/system/root'' [39.06 GB] inherit
>  ACTIVE            ''/dev/system/swap'' [9.75 GB] inherit
>
>
> I need to resize the 100GB /dev/data/cpanel002
1) shutdown the domu : xm shutdown ''name of domu''
   wait for the domu to be shutdown  (xm list)
2) reduce the filesystem : 
   If it''s ext3 :
      e2fsck -f -y /dev/data/cpanel00
      resize2fs -p /dev/data/cpanel00 90G
3) reduce the logical volume :
      lvreduce -L 90G /dev/data/cpanel00

4) restart the domu.

              Jean Charles
-- 
" Avec les machines NEDAP, le vote est TELLEMENT secret que même les
électeurs n''ont aucune garantie que leur vote soit réellement crédité
au
compte de voix du candidat de son choix ! "
     http://ordinateurs-de-vote.org/ --- http://vao-amiens.fdn.fr/

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

Rudi Ahlers wrote:
> Sorry John, but what you''re saying is very very confusing. I
don''t
> know LVM at all, and what I''ve done is purely by chance, and using
the
> defaults when installing CentOS.
Sorry, yes, I know it''s confusing.

What makes it worse is that there are two systems interacting here: the 
guest OS (whatever it is) and the host OS (whatever it is).

LVM first.   There''s good discussions of this in the Red Hat 
documentation and you should probably read that.  In a nut shell though, 
the building blocks are "physical volumes": these typically partitions
on disks and you can see them with fdisk or similar.   A "volume
group"
is built from one or more physical volumes.  "Logical volumes" are 
allocated from the space in a volume group.

If you''re starting with a couple of fresh disks that you''ve
just
installed in a computer you need to run fdisk, pvcreate, vgcreate and 
lvcreate in that order.   fdisk is used to create a partition and you 
usually create a single partition spanning the whole disk (there are 
loads of caveats here but I''m skipping them for simplicity).  So if
your
two new disks appear as /dev/sdb and /dev/sdc then you''ll create a 
single parition on each to get /dev/sdb1 and /dev/sdc1.   Next run 
"pvcreate /dev/sdb1" and "pvcreate /dev/sdc1" to create some
on-disk
data structures.   Now you can create a volume group to hold them: 
"vgcreate mygroup /dev/sdb1 /dev/sdc1" and finally you can create some
logical volumes, for example, "lvcreate -L 20G -n mydisk 
/dev/mygroup".   And finally finally you can, for example, create a file 
system in the newly created logical volume: "mke2fs -j 
/dev/mygroup/mydisk".   The man pages for pvcreate, vgcreate and 
lvcreate will tell you quite a lot, you should read them.

Now, suppose we discover that we need a parition on /dev/sdb for 
something other than LVM.  I don''t know what and it doesn''t
matter.
What you need to do is run fdisk and re-parition the disk so that part 
of it is for LVM and part of it is for the other partition.   Of course, 
when you ran "pvcreate /dev/sdb1" part of what got written into the 
on-disk data structures is the size of /dev/sdb1 and if you make 
/dev/sdb1 smaller then the on-disk data structures will be corrupt.   
Even worse, any logical volume that happened to be using a part of 
/dev/sdb1 that is no longer there (because it''s part of /dev/sdb2) will
be missing and any file system that''s in that logical volume will be 
corrupt.   You get the same sorts of problems if you put a file system 
in /dev/sdb1 and then using /dev/sdb1 smaller -- the end of the file 
system is missing and you''re in trouble.

So with LVM if you''re going to shrink /dev/sdb1 a bit you need to do 
some work to prepare for that: you need to shrink the physical volume.  
That''s easy -- check the man page for pvresize.   Now that the physical
volume isn''t using all of /dev/sdb1 you can use fdisk to make /dev/sdb1
a bit smaller.

pvresize will refuse to shrink the physical volume if there isn''t
enough
space.   "vgdisplay" (check the man page again) will tell you how much
free space (free "physical extents", PE) there are in the volume group
and "lvdisplay -m <logical volume>" will tell you exactly which
physical
extents any particular logical volume is using.  This is confusing.  
Check the man pages, look at the output of the commands, read the 
documentation.  It will make sense after a while.

Once is makes sense you can see that to shrink a physical volume you 
must free up physical extents at the end of the volume -- "pvdisplay -vm 
/dev/sdb1" (for example) will show you where physical extents are 
allocated.   So if you want to shrink a physical volume you may have to 
remove or shrink logical volumes and, of course, before you shrink a 
logical volume you need to shrink the file system contained within it.


Now we can get on to this issue of a domU''s "disk" being
contained in a
logical volume in dom0.   In this case, the "disk" that domU sees, 
typically /dev/xvda, is a logical volume in dom0.  In domU, fdisk 
/dev/xvda sees the parition table on the disk, pvcreate creates physical 
volumes within a parition on that disk and so on.  What I''ve said above
applies just as well to virtual disks called /dev/xvda and /dev/xvdb as 
it does to real disks called /dev/sdb and /dev/sdc.

The difference is that the disk as seen by domU is just a logical volume 
seen by dom0.  So if your dom0 "exports" /dev/data/cpanel1 as xvda to 
the domU then, to all intents and purposes, you should be able to treat 
/dev/data/cpanel1 as though it was a disk.  And you can.  If you run 
"fdisk -l /dev/data/cpanel1" then you can see a partition table and
you
can edit that partition table just as you would if it were a real disk.  
And, of course, if you shrink a partition then you had better make sure 
that you have shrunk what goes inside it first.

This is where the magic "kpartx" comes in.  This allows you to make
the
partitions within a logical volume visible as devices.   Run "kpartx 
/dev/data/cpanel1".  It tells you that there are two partitions.  Now 
run "ls /dev/mapper" and take note of what''s in there.  And
now run
"kpartx -va /dev/data/cpanel1" and "ls /dev/mapper" again.  
You now
have some new device files in /dev/mapper corresponding to the 
partitions inside that logical volume.  These are exactly the paritions 
that the guest OS sees inside /dev/xvda.   You need to try this and see 
what you''ve got.  And check the man page for kpartx so you know what 
you''re doing.

Now, for a standard CentOS installation in the guest, there''ll be two 
partitions in /dev/xvda: a 100MB one for /boot and one for everything 
else in a single volume group.  We can see the two partitions in 
/dev/mapper in dom0 now (after you''ve run kpartx appropriately) and you
can mount the first one as a file system and see that it is indeed the 
CentOS /boot.  The second partition, however, is a physical volume.  You 
can run "pvscan" to find all the physical volumes on a system and it 
will, indeed, find this one.  What''s more, you can run
"vgscan" to find
(and activate) all the defined volume groups.   If you do that then 
you''ll find the /dev/data and /dev/system volume groups that you
already
have in dom0 and one new one: VolGroup00, the volume group that holds 
the logical volumes for the CentOS guest.  There''s a man page for
vgscan
that explains it.  "vgdisplay /dev/VolGroup00" will now tell you
things
about the new volume group (man page again).

Now you can go through all that resizing stuff that you would go through 
if you were using a physical disk.

I''m sorry, I know this is confusing, but U think you''re just
going to
have to plug your way through all the various commands I''ve mentioned 
until you know what they all do.  Then you''ll be able to just sit down 
and do the resizing stuff.

jch

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

Jean Charles Delepine wrote:
> Rudi Ahlers <Rudi@SoftDux.com> écrivait (wrote) :
>
>   
>> This is what I have:
>>
>> [root@cPanel002 ~]# [root@HF-LINSRV01 ~]# lvscan
>>  ACTIVE            ''/dev/data/cpanel002'' [100.00 GB]
inherit
>>  ACTIVE            ''/dev/data/windows2003_web'' [30.00
GB] inherit
>>  ACTIVE            ''/dev/data/storage'' [50.00 GB]
inherit
>>  ACTIVE            ''/dev/data/cacti'' [20.00 GB]
inherit
>>  ACTIVE            ''/dev/data/cpanel2'' [30.00 GB]
inherit
>>  ACTIVE            ''/dev/system/root'' [39.06 GB]
inherit
>>  ACTIVE            ''/dev/system/swap'' [9.75 GB]
inherit
>>
>>
>> I need to resize the 100GB /dev/data/cpanel002
>>     
>
> 1) shutdown the domu : xm shutdown ''name of domu''
>    wait for the domu to be shutdown  (xm list)
> 2) reduce the filesystem : 
>    If it''s ext3 :
>       e2fsck -f -y /dev/data/cpanel00
>       resize2fs -p /dev/data/cpanel00 90G
>   
It''s not, it''s a disk image with two paritions, one of which
is ext3,
the other is a physical volume.  That''s what makes it so
complicated.
> 3) reduce the logical volume :
>       lvreduce -L 90G /dev/data/cpanel00
>
> 4) restart the domu.
>
>               Jean Charles
>   

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

Jean Charles Delepine wrote:
> Rudi Ahlers <Rudi@SoftDux.com> écrivait (wrote) :
>
>   
>> This is what I have:
>>
>> [root@cPanel002 ~]# [root@HF-LINSRV01 ~]# lvscan
>>  ACTIVE            ''/dev/data/cpanel002'' [100.00 GB]
inherit
>>  ACTIVE            ''/dev/data/windows2003_web'' [30.00
GB] inherit
>>  ACTIVE            ''/dev/data/storage'' [50.00 GB]
inherit
>>  ACTIVE            ''/dev/data/cacti'' [20.00 GB]
inherit
>>  ACTIVE            ''/dev/data/cpanel2'' [30.00 GB]
inherit
>>  ACTIVE            ''/dev/system/root'' [39.06 GB]
inherit
>>  ACTIVE            ''/dev/system/swap'' [9.75 GB]
inherit
>>
>>
>> I need to resize the 100GB /dev/data/cpanel002
>>     
>
> 1) shutdown the domu : xm shutdown ''name of domu''
>    wait for the domu to be shutdown  (xm list)
> 2) reduce the filesystem : 
>    If it''s ext3 :
>       e2fsck -f -y /dev/data/cpanel00
>       resize2fs -p /dev/data/cpanel00 90G
> 3) reduce the logical volume :
>       lvreduce -L 90G /dev/data/cpanel00
>
> 4) restart the domu.
>
>               Jean Charles
>   
I don''t think those commands will work on ext3

[root@HF-LINSRV01 i386]# e2fsck -f -y /dev/data/cpanel002
e2fsck 1.39 (29-May-2006)
Couldn''t find ext2 superblock, trying backup blocks...
e2fsck: Bad magic number in super-block while trying to open 
/dev/data/cpanel002

The superblock could not be read or does not describe a correct ext2
filesystem.  If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>


-- 

Kind Regards
Rudi Ahlers
CEO, SoftDux

Web:   http://www.SoftDux.com
Check out my technical blog, http://blog.softdux.com for Linux or other
technical stuff, or visit http://www.WebHostingTalk.co.za for Web Hosting stuff



_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

Rudi Ahlers wrote:
> Jean Charles Delepine wrote:
>> Rudi Ahlers <Rudi@SoftDux.com> écrivait (wrote) :
>>
>>  
>>> This is what I have:
>>>
>>> [root@cPanel002 ~]# [root@HF-LINSRV01 ~]# lvscan
>>>  ACTIVE            ''/dev/data/cpanel002'' [100.00
GB] inherit
>>>  ACTIVE            ''/dev/data/windows2003_web''
[30.00 GB] inherit
>>>  ACTIVE            ''/dev/data/storage'' [50.00 GB]
inherit
>>>  ACTIVE            ''/dev/data/cacti'' [20.00 GB]
inherit
>>>  ACTIVE            ''/dev/data/cpanel2'' [30.00 GB]
inherit
>>>  ACTIVE            ''/dev/system/root'' [39.06 GB]
inherit
>>>  ACTIVE            ''/dev/system/swap'' [9.75 GB]
inherit
>>>
>>>
>>> I need to resize the 100GB /dev/data/cpanel002
>>>     
>>
>> 1) shutdown the domu : xm shutdown ''name of domu''
>>    wait for the domu to be shutdown  (xm list)
>> 2) reduce the filesystem :    If it''s ext3 :
>>       e2fsck -f -y /dev/data/cpanel00
>>       resize2fs -p /dev/data/cpanel00 90G
>> 3) reduce the logical volume :
>>       lvreduce -L 90G /dev/data/cpanel00
>>
>> 4) restart the domu.
>>
>>               Jean Charles
>>   
> I don''t think those commands will work on ext3
>
> [root@HF-LINSRV01 i386]# e2fsck -f -y /dev/data/cpanel002
> e2fsck 1.39 (29-May-2006)
> Couldn''t find ext2 superblock, trying backup blocks...
> e2fsck: Bad magic number in super-block while trying to open 
> /dev/data/cpanel002
>
> The superblock could not be read or does not describe a correct ext2
> filesystem.  If the device is valid and it really contains an ext2
> filesystem (and not swap or ufs or something else), then the superblock
> is corrupt, and you might try running e2fsck with an alternate 
> superblock:
>    e2fsck -b 8193 <device>
>
>
That''s because /dev/data/cpanel002 isn''t a file system,
it''s a disk
image.  Run "kpartx /dev/data/cpanel002" to see what partitions there
are.

jch


_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

John Haxby wrote:
> Rudi Ahlers wrote:
>> Jean Charles Delepine wrote:
>>> Rudi Ahlers <Rudi@SoftDux.com> écrivait (wrote) :
>>>
>>>  
>>>> This is what I have:
>>>>
>>>> [root@cPanel002 ~]# [root@HF-LINSRV01 ~]# lvscan
>>>>  ACTIVE            ''/dev/data/cpanel002''
[100.00 GB] inherit
>>>>  ACTIVE           
''/dev/data/windows2003_web'' [30.00 GB] inherit
>>>>  ACTIVE            ''/dev/data/storage'' [50.00
GB] inherit
>>>>  ACTIVE            ''/dev/data/cacti'' [20.00
GB] inherit
>>>>  ACTIVE            ''/dev/data/cpanel2'' [30.00
GB] inherit
>>>>  ACTIVE            ''/dev/system/root'' [39.06
GB] inherit
>>>>  ACTIVE            ''/dev/system/swap'' [9.75
GB] inherit
>>>>
>>>>
>>>> I need to resize the 100GB /dev/data/cpanel002
>>>>     
>>>
>>> 1) shutdown the domu : xm shutdown ''name of domu''
>>>    wait for the domu to be shutdown  (xm list)
>>> 2) reduce the filesystem :    If it''s ext3 :
>>>       e2fsck -f -y /dev/data/cpanel00
>>>       resize2fs -p /dev/data/cpanel00 90G
>>> 3) reduce the logical volume :
>>>       lvreduce -L 90G /dev/data/cpanel00
>>>
>>> 4) restart the domu.
>>>
>>>               Jean Charles
>>>   
>> I don''t think those commands will work on ext3
>>
>> [root@HF-LINSRV01 i386]# e2fsck -f -y /dev/data/cpanel002
>> e2fsck 1.39 (29-May-2006)
>> Couldn''t find ext2 superblock, trying backup blocks...
>> e2fsck: Bad magic number in super-block while trying to open 
>> /dev/data/cpanel002
>>
>> The superblock could not be read or does not describe a correct ext2
>> filesystem.  If the device is valid and it really contains an ext2
>> filesystem (and not swap or ufs or something else), then the superblock
>> is corrupt, and you might try running e2fsck with an alternate 
>> superblock:
>>    e2fsck -b 8193 <device>
>>
>>
> That''s because /dev/data/cpanel002 isn''t a file system,
it''s a disk
> image.  Run "kpartx /dev/data/cpanel002" to see what partitions
there
> are.
>
> jch
>
>
kpartx doesn''t exist on a console only server.....

-- 

Kind Regards
Rudi Ahlers
CEO, SoftDux

Web:   http://www.SoftDux.com
Check out my technical blog, http://blog.softdux.com for Linux or other
technical stuff, or visit http://www.WebHostingTalk.co.za for Web Hosting stuff



_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

Rudi Ahlers wrote:
> kpartx doesn''t exist on a console only server.....
>
It''s not an X program :-)

$ rpm -qi kpartx
...
URL         : http://christophe.varoqui.free.fr/
Summary     : Partition device manager for device-mapper devices.
Description :
kpartx manages partition creation and removal for device-mapper devices.

jch

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users