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. > >>> > >> > > >
