cloudstack-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From cs user <acldstk...@gmail.com>
Subject Re: Cloudstack - volume migration between clusters (primary storage)
Date Thu, 25 Aug 2016 06:26:57 GMT
Hi Makrand,

Thanks for responding!

Yes this does work for us, for small disks. Even with small disks however
it seems to take a while, 5 mins or so, on a pretty fast 10GB network.

However currently I am trying to move 2TB disks which is taking a while,
and was hitting a 3 hour time limit which seemed to be a cloudstack default
for cloning disks.

Migrations within the cluster, as you say, seem to use Storage Xen motion
and these work fine with small disks. Haven't really tried huge ones with
that.

I think you are right that it is using the the SSVM, despite the fact I
can't seem to see much activity when the copy is occurring.

Thanks!



On Wed, Aug 24, 2016 at 7:36 PM, Makrand <makrandsanap@gmail.com> wrote:

> Hi,
>
> I think you must be seeing the option like (storage migration required)
> while you move the volumes between primary storage. I've seen in past
> people complaining about this option not working (using GUI or API) with
> setup similar as yours. Did you get this working?
>
> Anyways, I think it has to be system VM, coz primary storage A have not
> Idea about primary storage B via hypervisor, only cloudstack ( (SSVM) can
> see it as part as one cloud zone.
>
> In normal case of moving volume within cluster, Storge XEN motion is what
> it uses.
>
>
>
> --
> Makrand
>
>
> On Wed, Aug 24, 2016 at 7:50 PM, cs user <acldstkusr@gmail.com> wrote:
>
> > Hi All,
> >
> > Xenserver 6.5, cloudstack 4.5.2. NFS primary storage volumes
> >
> > Lets say I have 1 pod, with 2 clusters, each cluster has its own primary
> > storage.
> >
> > If I migrate a volume from one primary storage to the other one, using
> > cloudstack, what aspect of the environment is responsible for this copy?
> >
> > I'm trying to identify bottlenecks but I can't see what is responsible
> for
> > this copying. Is it is the xen hosts themselves or the secondary storage
> > vm?
> >
> > Thanks!
> >
>

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