Hi, dom0: Debian Lenny 2.6.26-2-xen-amd64, domU: same. Xen 3.2-1 After resizing a LV on dom0, Xen is not reporting the new extended size to the PV domU even though dom0 is well aware of the new size. I''ve rebooted domU (not dom0 yet as that''s running a lot of other domU''s). The LV I tried to resize is encrypted. Resizing unencrypted volumes works as expected. dom0:~# blockdev --getsz /dev/d/lv3 1258291200 domU:~# blockdev --getsz /dev/sdc1 1048576000 Any suggestions? regards, Jan
On Mon, Mar 19, 2012 at 4:05 PM, Jan Bakuwel <jan.bakuwel@gmail.com> wrote:> Hi, > > dom0: Debian Lenny 2.6.26-2-xen-amd64, domU: same. Xen 3.2-1 > > After resizing a LV on dom0, Xen is not reporting the new extended size > to the PV domU even though dom0 is well aware of the new size. I''ve > rebooted domU (not dom0 yet as that''s running a lot of other domU''s). > The LV I tried to resize is encrypted. Resizing unencrypted volumes > works as expected. > > dom0:~# blockdev --getsz /dev/d/lv3 > 1258291200Is this on the dom0?> > domU:~# blockdev --getsz /dev/sdc1 > 1048576000Is this on the domU? If yes, you need to resize the partition as well. Kinda hassle, somewhat. Your options are: - boot domU using sysrescuecd or similar live CD (assign the disk to another HVM domU if necessary), and resize the partition there. OR - map the disk to dom0 using "xm block-attach 0 ...", then use gparted/parted/whatever on dom0 for that disk. -- Fajar
Hi Fajar, On 19/03/12 22:11, Fajar A. Nugraha wrote:> On Mon, Mar 19, 2012 at 4:05 PM, Jan Bakuwel <jan.bakuwel@gmail.com> wrote: >> Hi, >> >> dom0: Debian Lenny 2.6.26-2-xen-amd64, domU: same. Xen 3.2-1 >> >> After resizing a LV on dom0, Xen is not reporting the new extended size >> to the PV domU even though dom0 is well aware of the new size. I''ve >> rebooted domU (not dom0 yet as that''s running a lot of other domU''s). >> The LV I tried to resize is encrypted. Resizing unencrypted volumes >> works as expected. >> >> dom0:~# blockdev --getsz /dev/d/lv3 >> 1258291200 > Is this on the dom0? > >> domU:~# blockdev --getsz /dev/sdc1 >> 1048576000 > Is this on the domU? > > If yes, you need to resize the partition as well. Kinda hassle, > somewhat. Your options are: > - boot domU using sysrescuecd or similar live CD (assign the disk to > another HVM domU if necessary), and resize the partition there. OR > - map the disk to dom0 using "xm block-attach 0 ...", then use > gparted/parted/whatever on dom0 for that disk.Yes to all the above. I''m not sure if I understand you. Please note dom0 exports the LVs to domU as discs, not partitions. I had to increase a few others LVs used by the same domU, those all resized as usual. The only LV that didn''t resize as expected is the one that is encrypted on domU. The LV has been resized on dom0 and if I used blockdev on dom0 to inquire the size of the device I''m getting the expected result so we''re beyond any resizing on dom0? domU has been rebooted. Once rebooted, domU''s kernel should see the correct size? kind regards, Jan
On Tue, Mar 20, 2012 at 4:42 AM, Jan Bakuwel <jan.bakuwel@gmail.com> wrote:> Yes to all the above. I''m not sure if I understand you. Please note dom0 > exports the LVs to domU as discs, not partitions.Doesn''t matter. What matters is what the domU USES the block device as. If you use some kind of installer to setup domU, then it will CREATE partitions (and optionally LVM) on top of the block device. If you create the domU manually (e.g. from template) then it''s your choice whether or not to create a partition on it.> I had to increase a > few others LVs used by the same domU, those all resized as usual. The > only LV that didn''t resize as expected is the one that is encrypted on domU. > > The LV has been resized on dom0 and if I used blockdev on dom0 to > inquire the size of the device I''m getting the expected result so we''re > beyond any resizing on dom0? domU has been rebooted. Once rebooted, > domU''s kernel should see the correct size?Here''s something that would help you understand better. In domU, do a "cat /proc/partitions" and "fdisk -lu". You should see that domU sees the "disk" HAS changed, but the partition ON that disk remains the same. -- Fajar
I think you need to resize the file system established on that LV volume. On Tue, Mar 20, 2012 at 5:53 AM, Fajar A. Nugraha <list@fajar.net> wrote:> On Tue, Mar 20, 2012 at 4:42 AM, Jan Bakuwel <jan.bakuwel@gmail.com> > wrote: > > Yes to all the above. I''m not sure if I understand you. Please note dom0 > > exports the LVs to domU as discs, not partitions. > > Doesn''t matter. > > What matters is what the domU USES the block device as. If you use > some kind of installer to setup domU, then it will CREATE partitions > (and optionally LVM) on top of the block device. > > If you create the domU manually (e.g. from template) then it''s your > choice whether or not to create a partition on it. > > > I had to increase a > > few others LVs used by the same domU, those all resized as usual. The > > only LV that didn''t resize as expected is the one that is encrypted on > domU. > > > > The LV has been resized on dom0 and if I used blockdev on dom0 to > > inquire the size of the device I''m getting the expected result so we''re > > beyond any resizing on dom0? domU has been rebooted. Once rebooted, > > domU''s kernel should see the correct size? > > Here''s something that would help you understand better. In domU, do a > "cat /proc/partitions" and "fdisk -lu". > You should see that domU sees the "disk" HAS changed, but the > partition ON that disk remains the same. > > -- > Fajar > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xen.org > http://lists.xen.org/xen-users >_______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users
Hi Fajar, ...snap...> Here''s something that would help you understand better. In domU, do a > "cat /proc/partitions" and "fdisk -lu". > You should see that domU sees the "disk" HAS changed, but the > partition ON that disk remains the sameNot really. Here''s the relevant part of the output from "cat /proc/partitions": domU:~# cat /proc/partitions major minor #blocks name 8 81 524288000 sdc1 254 0 524287484 dm-0 As you can see domU thinks sdc1 is 524288000 units. Then the relevant part of the output of "fdisk -lu" shows: domU:~# fdisk -lu ...snap... Disk /dev/sdc1: 536.8 GB, 536870912000 bytes 255 heads, 63 sectors/track, 65270 cylinders, total 1048576000 sectors Units = sectors of 1 * 512 = 512 bytes Disk identifier: 0x08020000 Disk /dev/sdc1 doesn''t contain a valid partition table ...snap... And "blockdev --getsz /dev/sdc1 shows: domU:~# blockdev --getsz /dev/sdc1 1048576000 I''m not using an installer to create my VMs but mount the LV on dom0, then unpack the tarball of my choice, unmount the LV on dom0 and start domU. I''ve been doing that for years; works like a charm. Now on dom0: dom0:~# blockdev --getsz /dev/d/lv3 1258291200 dom0:~# cat /proc/partitions ...snap... 254 3 629145600 dm-3 ...snap... 1258291200 / 2 (512 byte sectors) = 629145600 (1K blocks) cheers, Jan
Hi Feisky, On 20/03/12 14:13, Feisky wrote:> I think you need to resize the file system established on that LV volume.Yes, I need to do that too. But I''m not there yet. The underlying blockdevice reports the incorrect (old) size and therefore cryptsetup resize and xfs_growfs won''t do anything. cheers, Jan
Hi Shane, On 20/03/12 10:52, Shane Johnson wrote:> Jan - One thing that came to mind while reading your post, is do you > need to tell the the encryption mechanism to resize the disk? It > would seem that you would as from all the encryption tools I have > used, they encrypt the entire medium not just the data. Hope you find > your answer.Yes, I do have to tell the encryption mechanims to resize the encrypted volume as well. But I''m not there yet. The underlying blockdevice reports the incorrect (old) size so cryptsetup resize and xfs_growfs can''t do anything until they see that the size of the block device has increased. cheers, Jan
On Wed, Mar 21, 2012 at 5:29 AM, Jan Bakuwel <jan.bakuwel@gmail.com> wrote:> Here''s the relevant part of the output from "cat /proc/partitions": > > domU:~# cat /proc/partitions > major minor #blocks name > > 8 81 524288000 sdc1 > 254 0 524287484 dm-0> Now on dom0: > > dom0:~# cat /proc/partitions > ...snap... > 254 3 629145600 dm-3 > ...snap...Do you map the block device on domU as sdc1 or sdc? Or to put it another way, does domU has /dev/sdc? -- Fajar
On Wed, Mar 21, 2012 at 5:33 AM, Jan Bakuwel <jan.bakuwel@gmail.com> wrote:> Hi Shane, > > On 20/03/12 10:52, Shane Johnson wrote: >> Jan - One thing that came to mind while reading your post, is do you >> need to tell the the encryption mechanism to resize the disk? It >> would seem that you would as from all the encryption tools I have >> used, they encrypt the entire medium not just the data. Hope you find >> your answer. > > Yes, I do have to tell the encryption mechanims to resize the encrypted > volume as well. > But I''m not there yet. The underlying blockdevice reports the incorrect > (old) size so cryptsetup resize and xfs_growfs can''t do anything until > they see that the size of the block device has increased.Also, did you do encryption on dom0 side, or domU side? If it''s dom0 side, then Shane''s comments are correct. -- Fajar
Hi Fajar, On 21/03/12 11:55, Fajar A. Nugraha wrote:> On Wed, Mar 21, 2012 at 5:29 AM, Jan Bakuwel <jan.bakuwel@gmail.com> wrote: >> Here''s the relevant part of the output from "cat /proc/partitions": >> >> domU:~# cat /proc/partitions >> major minor #blocks name >> >> 8 81 524288000 sdc1 >> 254 0 524287484 dm-0 > >> Now on dom0: >> >> dom0:~# cat /proc/partitions >> ...snap... >> 254 3 629145600 dm-3 >> ...snap... > Do you map the block device on domU as sdc1 or sdc? Or to put it > another way, does domU has /dev/sdc?I''m mapping the device as sdc1, ie. domU has /dev/sdc1 but not /dev/sdc. cheers, Jan
Hi Fajar, On 21/03/12 11:56, Fajar A. Nugraha wrote:> On Wed, Mar 21, 2012 at 5:33 AM, Jan Bakuwel <jan.bakuwel@gmail.com> wrote: >> Hi Shane, >> >> On 20/03/12 10:52, Shane Johnson wrote: >>> Jan - One thing that came to mind while reading your post, is do you >>> need to tell the the encryption mechanism to resize the disk? It >>> would seem that you would as from all the encryption tools I have >>> used, they encrypt the entire medium not just the data. Hope you find >>> your answer. >> Yes, I do have to tell the encryption mechanims to resize the encrypted >> volume as well. >> But I''m not there yet. The underlying blockdevice reports the incorrect >> (old) size so cryptsetup resize and xfs_growfs can''t do anything until >> they see that the size of the block device has increased. > Also, did you do encryption on dom0 side, or domU side? > > If it''s dom0 side, then Shane''s comments are correct.The (luks) encryption is taking place in domU. dom0 only provides the storage. cheers, Jan
On Wed, Mar 21, 2012 at 10:50 AM, Jan Bakuwel <jan.bakuwel@gmail.com> wrote:> The (luks) encryption is taking place in domU. dom0 only provides the > storage.Then I''m out of ideas. In older kernels, rebooting the domU should be enough. In newer kernels, you could even recognize the size change with just a "partprobe", no need to reboot domU. At this point I''m guessing that there might be a bug your current kernel/xen versions. Since lenny is not current stable, I doubt there will be any interest to fix that. You should be able to permanently solve that by upgrading. Or maybe rebooting dom0 works. -- Fajar
Hi Fajar, On 21/03/12 17:05, Fajar A. Nugraha wrote:> On Wed, Mar 21, 2012 at 10:50 AM, Jan Bakuwel <jan.bakuwel@gmail.com> wrote: >> The (luks) encryption is taking place in domU. dom0 only provides the >> storage. > Then I''m out of ideas.Yeah, me too :-/> In older kernels, rebooting the domU should be enough. > In newer kernels, you could even recognize the size change with just a > "partprobe", no need to reboot domU.I did try partprobe - also without results.> At this point I''m guessing that there might be a bug your current > kernel/xen versions. Since lenny is not current stable, I doubt there > will be any interest to fix that.It must have something to do with the fact that the LV is (luks) encrypted since other volumes resize without issue (I''ve done that many times).> You should be able to permanently solve that by upgrading. Or maybe > rebooting dom0 works.I''ve scheduled a reboot of dom0 for the weekend and will inform the list if that solves the problem. thanks for your help so far, regards, Jan
On Wed, Mar 21, 2012 at 1:41 PM, Jan Bakuwel <jan.bakuwel@gmail.com> wrote:>> At this point I''m guessing that there might be a bug your current >> kernel/xen versions. Since lenny is not current stable, I doubt there >> will be any interest to fix that. > > > It must have something to do with the fact that the LV is (luks) > encrypted since other volumes resize without issue (I''ve done that many > times).But it shouldn''t. dom0 shouldn''t care what the domU uses the disk for, and domU''s xen block frontend shouldn''t really care what other kernel subsystem or userland uses the block device for. Whether it''s encrypted, or used for filesystem, or used as raw block device for database, or whatever. Unfortunately, like I said earlier, since you''re using old software there won''t be much interest in fixing this.> > >> You should be able to permanently solve that by upgrading. Or maybe >> rebooting dom0 works. > > I''ve scheduled a reboot of dom0 for the weekend and will inform the list > if that solves the problem.Good luck. -- Fajar
Hi Fajar, On 21/03/12 19:46, Fajar A. Nugraha wrote:> On Wed, Mar 21, 2012 at 1:41 PM, Jan Bakuwel <jan.bakuwel@gmail.com> wrote: > >>> At this point I''m guessing that there might be a bug your current >>> kernel/xen versions. Since lenny is not current stable, I doubt there >>> will be any interest to fix that. >> >> It must have something to do with the fact that the LV is (luks) >> encrypted since other volumes resize without issue (I''ve done that many >> times). > But it shouldn''t. > > dom0 shouldn''t care what the domU uses the disk for, and domU''s xen > block frontend shouldn''t really care what other kernel subsystem or > userland uses the block device for. Whether it''s encrypted, or used > for filesystem, or used as raw block device for database, or whatever.Can''t agree more.> Unfortunately, like I said earlier, since you''re using old software > there won''t be much interest in fixing this.Fair enough. I''m still hoping to find a workaround though.>>> You should be able to permanently solve that by upgrading. Or maybe >>> rebooting dom0 works. >> I''ve scheduled a reboot of dom0 for the weekend and will inform the list >> if that solves the problem. > Good luck.Thanks! Jan
Hi Fajar,> Unfortunately, like I said earlier, since you''re using old software > there won''t be much interest in fixing this.It turned out the software doesn''t need any fixing and works as advertised. The user might need a tune up (or more coffee) though. A (rather subtle) name change of the LV introduced a while ago fooled the user into picking the wrong LV. Duh! thanks again for your help, Jan