resizing Xen para-virtualized guest partition

[runmd]

I would like to know if it is possible to resizing Xen para-virtualized
guest partition.  For example,

I created a para-virtualized guest as 10GB.  Later down the road I would
like to grow it to 20GB.   Can I do this with it being just a file on Dom0.
The only possible solution I can think of is creating a new domU as 20GB and
then doing a dd command and copying one virutal disk to another.  But I
would like to just grow the guest, if possible.

Thanks
Terry

[Chris Lalancette]

runmd wrote:
>  
>  I created a para-virtualized guest as 10GB.  Later down the road I would 
>  like to grow it to 20GB.   Can I do this with it being just a file on 
>  Dom0.  The only possible solution I can think of is creating a new domU 
>  as 20GB and then doing a dd command and copying one virutal disk to 
>  another.  But I would like to just grow the guest, if possible. 
>  
>  Thanks
>  Terry
>   
There are two possible ways to do this; both rely on using LVM inside 
the guest to expand the LV.

1)  You should just be able to append data to the end of the disk in the 
dom0 (something like "dd if=/dev/zero count=10G >> 
/var/lib/xen/images/guest.dsk), and use "pvresize", vgextend, lvextend, 
and resize2fs inside the guest to expand the disk.

2)  If you are uncomfortable with the first method, you can define 
another disk and expand your LVM that way.  On the dom0 do something 
like "dd if=/dev/zero of=/var/lib/xen/images/guest-disk2.dsk count=10G", 
then add another line into your /etc/xen/guest configuration file for 
the second disk.  Then boot the guest, and inside the guest partition 
the disk with LVM partition, vgextend the VG with the new partition, and 
finally lvextend the LV with the new space.

If you aren't using LVM inside the guest, the best you are going to get 
away with is adding a second disk (like 2) above), and just mounting 
that inside the guest as another mountpoint.

Chris Lalancette

[Paul Wouters]

On Mon, 7 May 2007, Chris Lalancette wrote:

>  > like to grow it to 20GB.   Can I do this with it being just a
> file on Dom0.
>  > The only possible solution I can think of is creating a new domU as 20GB and
>  > then doing a dd command and copying one virutal disk to another.  But I
>  > would like to just grow the guest, if possible.
>  > Thanks
>  > Terry
>  >
>
>  There are two possible ways to do this; both rely on using LVM inside the
>  guest to expand the LV. 
>  1)  You should just be able to append data to the end of the disk in
> the dom0
>  (something like "dd if=/dev/zero count=10G >> /var/lib/xen/images/guest.dsk),
>  and use "pvresize", vgextend, lvextend, and resize2fs inside the guest to
>  expand the disk. 
You do not need LVM for that provided you have the disk space on the dom0:

dd if=/dev/zero bs=1M count=1024 >> /var/lib/xen/images/guest.dsk
e2fsck -f /var/lib/xen/images/guest.dsk
resize2fs /var/lib/xen/images/guest.dsk
e2fsck -f /var/lib/xen/images/guest.dsk

Paul

[Ranbir]

On Mon, 2007-05-07 at 15:07 -0400, Paul Wouters wrote:
>  You do not need LVM for that provided you have the disk space on the
> dom0:
>  
>  dd if=/dev/zero bs=1M count=1024 >> /var/lib/xen/images/guest.dsk
>  e2fsck -f /var/lib/xen/images/guest.dsk
>  resize2fs /var/lib/xen/images/guest.dsk
>  e2fsck -f /var/lib/xen/images/guest.dsk 
How do you do this if one installs the domU in a LV on dom0?  I thought
I could simply lvextend the dom0 LV, boot the domU, and then lv/vg/pv
extend inside the domU, but that didn't work.

Regards,

Ranbir
-- 
Kanwar Ranbir Sandhu
Linux 2.6.20-1.2944.fc6 i686 GNU/Linux 
09:22:03 up 7 days, 10 min, 2 users, load average: 0.09, 0.29, 0.33

[Ranbir]

On Sat, 2007-06-16 at 09:30 -0400, Kanwar Ranbir Sandhu wrote:
>  How do you do this if one installs the domU in a LV on dom0?  I
> thought
>  I could simply lvextend the dom0 LV, boot the domU, and then lv/vg/pv
>  extend inside the domU, but that didn't work. 
Let me add that I realize the domU file system  needs to be resized now,
but I haven't been able to figure out how to do that with "virt-install"
created domUs.

I also haven't figured out how to mount the LV domU file system in dom0.
This only mounts /boot (which is in the domU) on dom0:

lomount -t lvm -diskimage /dev/vg00/asterisk -partition 2 /mnt/xen/

Regards,

Ranbir

-- 
Kanwar Ranbir Sandhu
Linux 2.6.20-1.2944.fc6 i686 GNU/Linux 
09:44:44 up 7 days, 32 min, 2 users, load average: 0.29, 0.49, 0.39

[Ranbir]

On Sat, 2007-06-16 at 09:48 -0400, Kanwar Ranbir Sandhu wrote:
>  Let me add that I realize the domU file system  needs to be resized
> now,
>  but I haven't been able to figure out how to do that with "virt-install"
>  created domUs.
>  
>  I also haven't figured out how to mount the LV domU file system in dom0.
>  This only mounts /boot (which is in the domU) on dom0:
>  
>  lomount -t lvm -diskimage /dev/vg00/asterisk -partition 2 /mnt/xen/ 
I figured how to use kpartx to mount the domU LV in dom0.  I'm still
clued out on how to actually get the LV in the domU to see the bigger
dom0 LV it's installed in.

Regards,

Ranbir
-- 
Kanwar Ranbir Sandhu
Linux 2.6.20-1.2944.fc6 i686 GNU/Linux 
11:19:55 up 7 days, 2:08, 2 users, load average: 0.51, 0.39, 0.26

[Jeff Layton]

On Sat, 16 Jun 2007 09:30:27 -0400
Kanwar Ranbir Sandhu <m3freak(a)thesandhufamily.ca&gt; wrote:

>  On Mon, 2007-05-07 at 15:07 -0400, Paul Wouters wrote:
>  > You do not need LVM for that provided you have the disk space on the dom0:
>  > 
>  > dd if=/dev/zero bs=1M count=1024 >> /var/lib/xen/images/guest.dsk
>  > e2fsck -f /var/lib/xen/images/guest.dsk
>  > resize2fs /var/lib/xen/images/guest.dsk
>  > e2fsck -f /var/lib/xen/images/guest.dsk
>  
>  How do you do this if one installs the domU in a LV on dom0?  I thought
>  I could simply lvextend the dom0 LV, boot the domU, and then lv/vg/pv
>  extend inside the domU, but that didn't work.
>  
>  Regards,
>  
>  Ranbir 
So your entire xen disk is a LV in dom0, and the domU is using that
disk for the /boot partition and a PV for its own VG...

Resize the LV in dom0:

root@dom0# lvresize -L +5G /dev/VolGroup00/xendisk

...boot the domU. Run fdisk or some other partitioning utility in the
domU. Resize the partition there:

root@domU# fdisk /dev/xvda

...reboot the domU, since it'll still be in use. When it comes back, it
should see the new partition table. Now (assuming the PV for the domU
volgroup is /dev/xvda2):

root@domU# pvresize /dev/xvda2

...now the volgroup in the domU should see the new PE's. Resize the
LV's and extend the filesystem in the domU as you normally would.

I've done this several times and it's worked fine for me. There should
be no reason to import the VG into the dom0, unless you want to shrink
the domU root partition or something.

-- 
Jeff Layton <jlayton(a)redhat.com&gt;

[Ranbir]

On Sun, 2007-06-17 at 06:26 -0400, Jeff Layton wrote:
>  ...reboot the domU, since it'll still be in use. When it comes
> back, it
>  should see the new partition table. Now (assuming the PV for the domU
>  volgroup is /dev/xvda2):
>  
>  root@domU# pvresize /dev/xvda2 
Damn!  I figured everything else out, and this step completely escaped
me!  I figured I had to resize the LV, but didn't realize that the fdisk
bit actually changed the size of the "disk".

Thanks for the pointer.  I'm going to try it out - I'm sure it will
work.

-- 
Kanwar Ranbir Sandhu
Linux 2.6.20-1.2944.fc6 i686 GNU/Linux 
12:28:31 up 16 days, 3:15, 3 users, load average: 0.37, 0.27, 0.20

[John Summerfield]

runmd wrote:
>  I would like to know if it is possible to resizing Xen
> para-virtualized
>  guest partition.  For example,
>  
>  I created a para-virtualized guest as 10GB.  Later down the road I would
>  like to grow it to 20GB.   Can I do this with it being just a file on Dom0.
>  The only possible solution I can think of is creating a new domU as 20GB 
>  and
>  then doing a dd command and copying one virutal disk to another.  But I
>  would like to just grow the guest, if possible. 
Ignoring LVM (which might make things different), you can enlarge the 
underlying file with a careful incantation of dd. Practice elsewhere 
first, and/or back it up.
Something like this, but do read the docs:

dd of=whatsit skip=<biggernumber> count=0

Then do whatever you do to fix a real disk after using dd to copy disk 
to bigger disk.

btw You can create sparse files in the first place:
dd if=/dev/zero of=/tmp/ext-fs seek=$((4*1024*1024)) count=0
mke2fs -F -q /tmp/ext-fs

then
ls -Slosh /tmp/ext-fs

-- 

Cheers
John

-- spambait
1aaaaaaa(a)coco.merseine.nu  Z1aaaaaaa(a)coco.merseine.nu

Please do not reply off-list

[Paul Wouters]

On Tue, 8 May 2007, John Summerfield wrote:

>  btw You can create sparse files in the first place:
>  dd if=/dev/zero of=/tmp/ext-fs seek=$((4*1024*1024)) count=0
>  mke2fs -F -q /tmp/ext-fs 
I understood that using sparse files will significantly slow down
the xenu for the first time, as it keeps growing the fs allocation
underneath it.

Paul

[Daniel P. Berrange]

On Mon, May 07, 2007 at 08:41:29PM -0400, Paul Wouters wrote:
>  On Tue, 8 May 2007, John Summerfield wrote:
>  
>  > btw You can create sparse files in the first place:
>  > dd if=/dev/zero of=/tmp/ext-fs seek=$((4*1024*1024)) count=0
>  > mke2fs -F -q /tmp/ext-fs
>  
>  I understood that using sparse files will significantly slow down
>  the xenu for the first time, as it keeps growing the fs allocation
>  underneath it. 
That is correct. Never use sparse files if you care about performance
as they exhibit pathelogically bad behaviour while growing the allocation.
Pre-allocation a file should give the best performance for file backed
guests, as close as you'll get to native without using physical devices
directly.

With a little tweaking to the dd command shown above though it ought to
be possible to extend the image, while allocating the data. You basically
want to seek=<current end of file>  and then count=<additional space>
desired.

Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  [phone] -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|

[John Summerfield]

Daniel P. Berrange wrote:
>  On Mon, May 07, 2007 at 08:41:29PM -0400, Paul Wouters wrote:
> > On Tue, 8 May 2007, John Summerfield wrote:
> >
> >> btw You can create sparse files in the first place:
> >> dd if=/dev/zero of=/tmp/ext-fs seek=$((4*1024*1024)) count=0
> >> mke2fs -F -q /tmp/ext-fs
> > I understood that using sparse files will significantly slow down
> > the xenu for the first time, as it keeps growing the fs allocation
> > underneath it.
>  
>  That is correct. Never use sparse files if you care about performance
>  as they exhibit pathelogically bad behaviour while growing the allocation.
>  Pre-allocation a file should give the best performance for file backed
>  guests, as close as you'll get to native without using physical devices
>  directly.
>  
>  With a little tweaking to the dd command shown above though it ought to
>  be possible to extend the image, while allocating the data. You basically
>  want to seek=<current end of file>  and then count=<additional space>
>  desired.
>  
>  Dan. 
Please read ny sig. I really do not want off-list replies. Once I have 
ADSL at home when I move house, hopefully in a couple of weeks, they 
will simply bounce.

Daniel, are you able to sort out the list owner to get replies going, by 
default, to the list?

Thank so much.



-- 

Cheers
John

-- spambait
1aaaaaaa(a)coco.merseine.nu  Z1aaaaaaa(a)coco.merseine.nu

Please do not reply off-list

[Paul Wouters]

On Tue, 8 May 2007, John Summerfield wrote:

[useful answer by Dan]

>  Please read ny sig. I really do not want off-list replies. Once I
> have ADSL at
>  home when I move house, hopefully in a couple of weeks, they will simply
>  bounce. 
Someone takes the effort to help you by hitting "reply" and you're whining
about receiving a duplicate message you could have filtered out with procmail
on a properly connected server if it was *that* important to you:

              :0 Wh: msgid.lock
              | formail -D 8192 msgid.cache

Adding this to your procmail takes less time, and less characters for your
to download once your messages with the above three lines hit your own
mailing list membership :P

If you would cause bounces on the lists that I maintain, you'd simply be
unsubscribed, just like people with out of office replies or badly looping
forward rules.

Paul

[John Summerfield]

Paul Wouters wrote:
>  On Tue, 8 May 2007, John Summerfield wrote:
>  
>  [useful answer by Dan]
>  
> > Please read ny sig. I really do not want off-list replies. Once I have ADSL at
> > home when I move house, hopefully in a couple of weeks, they will simply
> > bounce.
>  
>  Someone takes the effort to help you by hitting "reply" and you're whining
You got that wrong. I am offering help. Read what I said.

>  about receiving a duplicate message you could have filtered out with
> procmail
>  on a properly connected server if it was *that* important to you: 
No, the default operation of mailman is to recognise the cc: and not 
send to anyone in the cc: list.
>  
>                :0 Wh: msgid.lock
>                | formail -D 8192 msgid.cache 
That assumes that everyone can use procmail. Not everyone has that 
access, and not all mail setups use procmail for delivery. If you read 
the dovecot+sendmail instructions at the dovecot site you will see one 
that doesn't.

>  
>  Adding this to your procmail takes less time, and less characters for your
>  to download once your messages with the above three lines hit your own
>  mailing list membership :P 
You simply do not understand my setup. Until you do, not cannot offer 
useful advice.
>  
>  If you would cause bounces on the lists that I maintain, you'd simply be
>  unsubscribed, just like people with out of office replies or badly looping
>  forward rules. 
Hopefully, lists you manage facilitate discussion by directing replies 
to the list.

In any case, the bounces will only be to those who reply off-list, and 
they're designed not to irritate those folk, but to defeat spammers. I 
do not have an email address that does not get spammed, but I have 
thought of how to make them clean.

It involves firewall rules that direct access from approved sources 
(those that host lists I am interested in) to the mail server where 
those email accounts are known. Email from other sources will be bounced 
"recipient unknown" if I'm in a good humour at the time. Alternatives 
are to reject or drop the connexion attempts.



-- 

Cheers
John

-- spambait
1aaaaaaa(a)coco.merseine.nu  Z1aaaaaaa(a)coco.merseine.nu

Please do not reply off-list

[Markus Armbruster]

John Summerfield <debian(a)herakles.homelinux.org&gt; writes:

[...]
>  Please read ny sig. I really do not want off-list replies. Once I
> have
>  ADSL at home when I move house, hopefully in a couple of weeks, they
>  will simply bounce.
>
>  Daniel, are you able to sort out the list owner to get replies going,
>  by default, to the list?
>
>  Thank so much. 
This just replaces one set of problems with a different set of
arguably worse problems, shifting the annoyance from one set of people
(which includes John) to another set (which includes me).

http://www.unicom.com/pw/reply-to-harmful.html

Every time you munge a header, God kills a kitten.  Please don't do
it.  Thank you so much.

[Eric Brunson]

Markus Armbruster wrote:
>  John Summerfield <debian(a)herakles.homelinux.org&gt; writes:
>
>  [...]
>    
> > Please read ny sig. I really do not want off-list replies. Once I have
> > ADSL at home when I move house, hopefully in a couple of weeks, they
> > will simply bounce.
> >
> > Daniel, are you able to sort out the list owner to get replies going,
> > by default, to the list?
> >
> > Thank so much.
> >     
>
>  This just replaces one set of problems with a different set of
>  arguably worse problems, shifting the annoyance from one set of people
>  (which includes John) to another set (which includes me).
>
>  http://www.unicom.com/pw/reply-to-harmful.html
>
>  Every time you munge a header, God kills a kitten.  Please don't do
>  it.  Thank you so much.
>     
Just because someone writes something and sticks it on the web page 
doesn't mean it's correct.

http://www.metasystema.net/essays/reply-to.mhtml

I personally prefer the list to set the Reply-To.  It came from the 
list, it should return to the list, I don't like getting two copies of 
replies to my posts and if someone wants to send me a reply off-list, 
they should have to work for it.  In the end it's a personal preference 
and whether you do it or not, each decision has its pros and cons.

[Daniel P. Berrange]

On Tue, May 08, 2007 at 10:22:24AM -0600, Eric Brunson wrote:
>  Markus Armbruster wrote:
>  >John Summerfield <debian(a)herakles.homelinux.org&gt; writes:
>  >
>  >[...]
>  >  
>  >>Please read ny sig. I really do not want off-list replies. Once I have
>  >>ADSL at home when I move house, hopefully in a couple of weeks, they
>  >>will simply bounce.
>  >>
>  >>Daniel, are you able to sort out the list owner to get replies going,
>  >>by default, to the list?
>  >>
>  >>Thank so much.
>  >>    
>  >
>  >This just replaces one set of problems with a different set of
>  >arguably worse problems, shifting the annoyance from one set of people
>  >(which includes John) to another set (which includes me).
>  >
>  >http://www.unicom.com/pw/reply-to-harmful.html
>  >
>  >Every time you munge a header, God kills a kitten.  Please don't do
>  >it.  Thank you so much.
>  >  
>  
>  Just because someone writes something and sticks it on the web page 
>  doesn't mean it's correct.
>  
>  http://www.metasystema.net/essays/reply-to.mhtml
>  
>  I personally prefer the list to set the Reply-To.  It came from the 
>  list, it should return to the list, I don't like getting two copies of 
>  replies to my posts and if someone wants to send me a reply off-list, 
>  they should have to work for it.  In the end it's a personal preference 
>  and whether you do it or not, each decision has its pros and cons. 
This pretty much sums it up. No matter what the list is set to people are
going to be unhappy. So I'm going to make myself happy instead & not change
it :-)

Regards,
Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  [phone] -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|

[Eric Brunson]

Daniel P. Berrange wrote:
>  On Tue, May 08, 2007 at 10:22:24AM -0600, Eric Brunson wrote:
>    
> > Markus Armbruster wrote:
> >     
> >> John Summerfield <debian(a)herakles.homelinux.org&gt; writes:
> >>
> >> [...]
> >>  
> >>       
> >>> Please read ny sig. I really do not want off-list replies. Once I have
> >>> ADSL at home when I move house, hopefully in a couple of weeks, they
> >>> will simply bounce.
> >>>
> >>> Daniel, are you able to sort out the list owner to get replies going,
> >>> by default, to the list?
> >>>
> >>> Thank so much.
> >>>    
> >>>         
> >> This just replaces one set of problems with a different set of
> >> arguably worse problems, shifting the annoyance from one set of people
> >> (which includes John) to another set (which includes me).
> >>
> >> http://www.unicom.com/pw/reply-to-harmful.html
> >>
> >> Every time you munge a header, God kills a kitten.  Please don't do
> >> it.  Thank you so much.
> >>  
> >>       
> > Just because someone writes something and sticks it on the web page 
> > doesn't mean it's correct.
> >
> > http://www.metasystema.net/essays/reply-to.mhtml
> >
> > I personally prefer the list to set the Reply-To.  It came from the 
> > list, it should return to the list, I don't like getting two copies of 
> > replies to my posts and if someone wants to send me a reply off-list, 
> > they should have to work for it.  In the end it's a personal preference 
> > and whether you do it or not, each decision has its pros and cons.
> >     
>
>  This pretty much sums it up. No matter what the list is set to people are
>  going to be unhappy. So I'm going to make myself happy instead & not change
>  it :-)
>     
Subscribing to "The Principle of Minimal Configuration Changes" makes 
you a man after my own heart.  :-)