Can I increase the size of a Linux VM's .vmdk disk without a reboot?

[dinny]

Hiya,

I've read a few articles that suggest that it should be possible to increase the size of a linux VM's disk (running off a single vmdk) without a reboot.

(Presuming that you are using LVM, by creating a new partition in the extra space on the single disk)

I can easily increase the size of the single .vmdk in the VI client, but I can't find any way of making fdisk on the VM actually see the extra space - other than by rebooting.

I've seen a couple of articles that suggest that:

echo 1 > /sys/block/sda/device/rescan

should do the trick - but it does not work for me.

(I appreciate that I could just add a new vmdk to the VM, then scan the scsi bus, and I would then be able to see that new disk with no reboot - but I was interested to know if it was also possible to do it via increasing the initial vmdk file)

Has anyone found a procedure that makes this possible?

(I am running ESX 3.5 u3 and the VM is RH 5.2)

Cheers

Dinny

[kjb007]

They would be much more than symlinks. Since the names won't change but will be based on more than just their relative order in the tree, they would be more resilient to these type of issues. Similar to what ESX does with using UUID/NAA instead of the dev names. Otherwise, we wouldn't be able to add new devices very easily, and would not be very nice when path failovers occurred.

-KjB

VMware vExpert

[dinny]

Hiya,

I was happy that the new names would be resilient - I used the word symlink as that is what the udev parameter that sets the permanent name seems to be called - but I appreciate that they would be different to the usual symlinks.

What I was presuming though was that the kernel/OS would still insist on using the sda/sdb name - so I (or rather the OS) would still have issues, and only anything specifically instructed to use the new permanent name would remain unaffected?

Was that your understanding too?

If not, maybe I should persue the udev idea further...

Dinny

[kjb007]

Not exactly. It will require some work to set up.

• udev supports persistent device naming, which does not depend on,
  for example, the order in which the devices are plugged into the
  system. The default udev setup provides persistent names for storage
  devices. Any hard disk is recognized by its unique filesystem id, the
  name of the disk and the physical location on the hardware it is
  connected to.

• udev executes entirely in user space, as opposed to devfs' kernel space.
  One consequence is that udev moved the naming policy out of the kernel
  and can run arbitrary programs to compose a name for the device from
  the device's properties, before the node is created.

-KjB

VMware vExpert

[Texiwill]

Hello,

Moved to Virtual Machine and Guest OS forum.

Best regards, Edward L. Haletky VMware Communities User Moderator, VMware vExpert 2009
Now Available on Rough-Cuts: 'VMware vSphere(TM) and Virtual Infrastructure Security: Securing ESX and the Virtual Environment'[/url]
Also available 'VMWare ESX Server in the Enterprise'[/url]
[url=http://www.astroarch.com/wiki/index.php/Blog_Roll]SearchVMware Pro[/url]|Blue Gears[/url]|Top Virtualization Security Links[/url]|Virtualization Security Round Table Podcast[/url]

[Rabie]

I have gone through the same pains as well with the current status being that afaiks in RHEL 5 there is no way to increase an active disk while it's in use.

The SCSI remove/add does work if the disk dev in not open (read not in use), it the sees the bigger disk and you can happily in fdisk either extend the partitions or create extra partitions and extend you VG's

However as soos as a disk is in use, then when you do the remove/add it sticks the disk on the next availible /dev/sdX as it cannot close the old device name.

I suppose if you had multipath configured and could get it to rescan and you had lvm pointing to the mpath devices you might be ok, I dont however know what will happen during the transition phase if you will 'loose' data.

The only work arround for now is to allocate a new vmdk, extend my VG's, then when you have a maint slot, grow the inital target disk, reboot the box, use fdisk to grow the lvm partition, then do a pvmove of the data from the temp disk to the grown disk, remove the temp disk from VG, shut down, remove the disk and boot for a last time. (there are a couple of steps not mentioned in there for time sake, lemme know if you want em all?)

It's messy, it's annoying I wish there was a better way. And now with win2008 having hot add(/remove?) of CPU and Memory, we (the linux crowed) seems to be lagging (please someone prove me wrong )

[dinny]

Thanks for that,

Good to know I'm not just missing something obvious

Dinny

[marmarama]

This works on RHEL5:

# blockdev --rereadpt <block device file>

e.g.

# blockdev --rereadpt /dev/sda

The kernel will then pickup the changed disk size and LVM, fdisk and friends will see the changed size.