Weblog entry #19 for dkg
See all weblog entries made by dkg.
If i resize one of the logical volumes from the dom0, how can i convince the domU to learn of the change in the underlying size? Is it possible to do this without restarting the domU? I haven't had any luck searching the 'net.
On the domU,i saw that the block device in question is 10G:
0 domU:~# cat /proc/partitions major minor #blocks name 8 1 10485760 sda1 8 2 524288 sda2 8 3 10485760 sda3 253 0 10485244 dm-0 0 domU:~#and on the dom0, i check that it looks right, and then lvresize it:
0 dom0:~# lvs LV VG Attr LSize Origin Snap% Move Log Copy% domU-disk vg0 -wi-ao 10.00G domU-srv vg0 -wi-ao 10.00G domU-swap vg0 -wi-ao 512.00M dom0 vg0 -wi-ao 1.00G 0 dom0:~# lvresize --size +2G vg0/domU-srv Extending logical volume domU-srv to 12.00 GB Logical volume domU-srv successfully resized 0 dom0:~#but domU:/proc/partitions still looks the same. I've tried installing hdparm on the domU and creating a fake /dev/sda for it to "re-read the partition table from", but that didn't work:
0 domU:~# mknod /dev/sda b 8 1 0 domU:~# hdparm -z /dev/sda /dev/sda: BLKRRPART failed: Invalid argument 0 domU:~# cat /proc/partitions major minor #blocks name 8 1 10485760 sda1 8 2 524288 sda2 8 3 10485760 sda3 253 0 10485244 dm-0 0 domU:~#any suggestions for what else i should try? Is there a xen-specific command to alert the domU of such a change?
Comments on this Entry
[ Send Message | View Steve's Scratchpad | View Weblogs ]
A) After resizing the LVM partition you need to resize the filesystem which is stored upon it.
B) You must shut down the guest before you do this.
xm shutdown domU.. e2fsck -f / /dev/vg0/domU-srv resize2fs / /dev/vg0/domU-srv xm create domU...
See our previous LVM cookbook for more examples.
[ Parent | Reply to this comment ]
[ Send Message | View dkg's Scratchpad | View Weblogs ]
Besides, if it is already a filesystem (and currently mounted in the domU, and the filesystem is ext3, and the domU is running a modern kernel), resize2fs can grow filesystems while mounted these days, as long as it can see the larger underlying block device.
So i guess this doesn't quite give me the answer i'm looking for yet. If a Xen guest needs to be rebooted to see a change in size of a block device, that's one thing. But i don't think resize2fs on its own is a reason to have to reboot.
[ Parent | Reply to this comment ]
[ Send Message | View Steve's Scratchpad | View Weblogs ]
Hmmm, yes I see what you're saying.
To be honest I'd suggest restarting the domU to see if it picks up the adjusted size at restart time - because I can't think of a way to force it to be refreshed.
There are ways to add/remove block devices if you're using HVM, but for "normal" Xen guests there isn't anything there.
[ Parent | Reply to this comment ]
[ Send Message | View dkg's Scratchpad | View Weblogs ]
0 domU:~# grep sda3 /proc/partitions 8 3 2097152 sda3 0 domU:~#
0 dom0:~# lvresize --size +1G vg0/domU-srv Extending logical volume domU-srv to 3.00 GB Logical volume domU-srv successfully resized 0 dom0:~# xm block-list domU Vdev BE handle state evt-ch ring-ref BE-path 2049 0 0 4 6 8 /local/domain/0/backend/vbd/11/2049 2050 0 0 4 7 9 /local/domain/0/backend/vbd/11/2050 2051 0 0 4 9 619 /local/domain/0/backend/vbd/11/2051 0 dom0:~# xm block-detach domU 2051 0 dom0:~# xm block-attach domU phy:vg0/domU-srv /dev/sda3 w 0 dom0:~#
0 domU:~# grep sda3 /proc/partitions 8 3 3145728 sda3 0 domU:~#Unfortunately, if i have the block device mounted in the domU, and i try this, the block-detach command claims to work on the dom0, but the block-list shows otherwise:
0 dom0:~# xm block-list domU Vdev BE handle state evt-ch ring-ref BE-path 2049 0 0 4 6 8 /local/domain/0/backend/vbd/11/2049 2050 0 0 4 7 9 /local/domain/0/backend/vbd/11/2050 2051 0 0 4 9 760 /local/domain/0/backend/vbd/11/2051 0 dom0:~# xm block-detach domU 2051 0 dom0:~# xm block-list domU Vdev BE handle state evt-ch ring-ref BE-path 2049 0 0 4 6 8 /local/domain/0/backend/vbd/11/2049 2050 0 0 4 7 9 /local/domain/0/backend/vbd/11/2050 2051 0 0 4 9 760 /local/domain/0/backend/vbd/11/2051 0 dom0:~#when i did that block-detach, this message spewed on the console of the domU as well:
vbd vbd-2051: 16 Device in use; refusing to closeOnce i unmount the filesystem, it appears to actually cause the underlying device to be released:
0 domU:~# umount /dev/sda3 0 domU:~#
0 dom0:~# xm block-list domU Vdev BE handle state evt-ch ring-ref BE-path 2049 0 0 4 6 8 /local/domain/0/backend/vbd/11/2049 2050 0 0 4 7 9 /local/domain/0/backend/vbd/11/2050 0 dom0:~#So, i'm most of the way there. i could do it without a reboot, as long as the block device is not mounted within the domU. But what i really want is what Steve assumed i wanted from the beginning: i want to resize the underlying block device while a filesystem on it is mounted within the domU, and i haven't figured out how to do that yet. Any other suggestions?
[ Parent | Reply to this comment ]
[ Send Message | View dkg's Scratchpad | View Weblogs ]
Wish i knew more about why the functionality wasn't considered important. It would be really useful for me.
[ Parent | Reply to this comment ]
Of course, you can still increase your capacity by using LVM in domU and importing addition partitions into the vm via xm block-attach followed by lvextend within domU.
Unfortunately, this adds a lot of complexity because your domU needs an LVM setup. Also your vm's file system is spread accross multiple backend (dom0) devices. This makes some things a pain. For example, it's yucky to snapshot and backup your vm's file system when it spread over multiple dom0 backend devices.
Therefore, unless it is some kind of kernel limitation, it seems reasonable to restore this functionality.
[ Parent | Reply to this comment ]