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 <[email protected]> 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 <[email protected]>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" <[email protected]> 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 <[email protected]> >>>>> 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 <[email protected]> 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. >>>>>> >>>>> >>>> >>> >> >> >
