Hi Kirk and all, I managed to resolve the problem, I am now able to resize the volume provided that I follow below steps:
- stop the VM; - detach the volume from the VM; - resize the volume; - re-attach the volume; - restart the VM. Both upgrade and downgrade work fine now. Many thanks for your help. Cheers. On Tue, Oct 8, 2013 at 3:19 AM, Kirk Kosinski <kirkkosin...@gmail.com>wrote: > Hi, I don't know how RBD works. If there are qcow2 files that you can > "see", you can check them with qemu-img. If there are no files I think > resizing on RBD probably doesn't work since the script that does the > resize only supports resizing qcow2 files and CLVM volumes. > > Best regards, > Kirk > > On 10/06/2013 06:42 PM, Indra Pramana wrote: > > Dear Marcus, Kirk and all, > > > > Any further recommendations on how can I troubleshoot on this matter to > > pinpoint the cause of the inability to resize the disk, and to find the > > solution to the problem? > > > > Looking forward to your reply, thank you. > > > > Cheers. > > > > > > > > On Fri, Oct 4, 2013 at 3:30 PM, Indra Pramana <in...@sg.or.id> wrote: > > > >> Hi Marcus and Kirk, > >> > >> Good day to you, and thank you for your email replies. > >> > >> We are using Ceph RBD primary storage. I can't find any error > information > >> on agent.log, and I have set the logging to verbose (DEBUG) for all. > >> > >> Since I am using RBD, am I still able to run the qemu-img info command? > >> > >> I check the volumes table contain load of information. How do I check > >> which record is referring to the virtual disk in question? > >> > >> Looking forward to your reply, thank you. > >> > >> Cheers. > >> > >> > >> > >> On Fri, Oct 4, 2013 at 6:58 AM, Kirk Kosinski <kirkkosin...@gmail.com > >wrote: > >> > >>> Yes, if there was a problem it should have been logged in the > agent.log. > >>> If it was successful it may or may not be logged depending on the > >>> logging level. While logged on to the hypervisor, check the actual > >>> virtual disk with "qemu-img info /mnt/somepath/filename". The filename > >>> can be found in the CloudStack database (the "path" field for the > >>> virtual disk in the volumes table). > >>> > >>> Best regards, > >>> Kirk > >>> > >>> On 10/03/2013 03:47 PM, Marcus Sorensen wrote: > >>>> What primary storage are you using? Any errors in agent log? > >>>> On Oct 3, 2013 3:16 PM, "Indra Pramana" <in...@sg.or.id> wrote: > >>>> > >>>>> Hi Marcus, > >>>>> > >>>>> Good day to you, and thank you for your e-mail. > >>>>> > >>>>> I have tried restarting the VM and even stop and start the VM, but > >>> after > >>>>> logging in to the VM, I still see the hard drive's size as 20 GB > >>> instead of > >>>>> 60 GB. > >>>>> > >>>>> I tried to check /var/log/libvirt/libvirtd.log file on the KVM host > >>> where > >>>>> the VM is hosted, and can't find any messages related to > >>> volBlockResize. > >>>>> > >>>>> Any other troubleshooting steps you can recommend, i.e. any other > area > >>> I > >>>>> can look into? > >>>>> > >>>>> Looking forward to your reply, thank you. > >>>>> > >>>>> Cheers. > >>>>> > >>>>> > >>>>> > >>>>> On Fri, Oct 4, 2013 at 4:46 AM, Marcus Sorensen <shadow...@gmail.com > > > >>>>> wrote: > >>>>> > >>>>>> I just tested local storage qcow2 and CLVM resize on 4.2, they both > >>>>> worked. > >>>>>> > >>>>>> Resize works like this: > >>>>>> > >>>>>> 1. Do sanity checks > >>>>>> 2. Send resize command to the agent > >>>>>> 3. Resize the disk/lun/file > >>>>>> 4. Inform the VM instance that the disk has changed by making a > >>>>>> libvirt volBlockResize call (this is not fatal, some guest types > can't > >>>>>> resize online and need to be restarted) > >>>>>> 5. Update the database > >>>>>> > >>>>>> You can check #3 looking at the disks themselves on storage to see > if > >>>>>> they've grown. You can check #4 by restarting the VM to see if it > >>>>>> picks up the change. > >>>>>> > >>>>>> It may be that libvirt was unable to inform the VM of the change > (for > >>>>>> example if you haven't upgraded to a supported version of Ubuntu or > >>>>>> CentOS and it has an old libvirt that doesn't support > volBlockResize). > >>>>>> The way to know for sure is stop/start the VM if you can. > >>>>>> > >>>>>> Look at those two things and let us know > >>>>>> > >>>>>> On Thu, Oct 3, 2013 at 2:33 PM, Indra Pramana <in...@sg.or.id> > wrote: > >>>>>>> Dear all, > >>>>>>> > >>>>>>> After upgrading to 4.2.0, I tried to resize a data disk of a VM > >>>>> instance > >>>>>>> from 20 GB to 60 GB, through the Cloudstack GUI. The UI reports > that > >>>>> the > >>>>>>> resize was successful, and that the data disk is now showing 60 GB > >>>>>> instead > >>>>>>> of 20 GB. However, when I check the actual disk on the VM, it seems > >>>>> that > >>>>>>> it's still 20 GB. > >>>>>>> > >>>>>>> Any reason what might have been the cause of the problem? I even > >>> tried > >>>>> to > >>>>>>> re-partition it to see if the size changed, but it wasn't and still > >>> at > >>>>> 20 > >>>>>>> GB. Which logs I need to look into? > >>>>>>> > >>>>>>> Any help on this is greatly appreciated. > >>>>>>> > >>>>>>> Looking forward to your reply, thank you. > >>>>>>> > >>>>>>> Cheers. > >>>>>> > >>>>> > >>>> > >>> > >> > >> > > >