cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Indra Pramana <in...@sg.or.id>
Subject [SOLVED] Re: Resize data-disk doesn't work after upgrade
Date Tue, 08 Oct 2013 02:54:19 GMT
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 <kirkkosinski@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 <indra@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 <kirkkosinski@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" <indra@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 <shadowsor@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 <indra@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.
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> >>
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message