Yep, I've narrowed this down to it running on the xen host. You can see it
in two ways on the xen host:
# xe task-list
uuid ( RO) : 69w52567-124h-14r5-16vb-2c4567143541
name-label ( RO): Async.VDI.copy
name-description ( RO):
status ( RO): pending
progress ( RO): 0.700
This actually gives you the percentage completed as well.
Also look for the process with:
ps -ef|grep sparse_dd
You will see a process running with a parameter which shows the size of the
disk, like:
-size 2147483648000 -prezeroed
( 2T in my case :-) )
So once the migration begins, you can look for it on your xen hosts in the
cluster, it usually starts on the same host as the VM to which the disk was
attached to.
On Tue, Aug 30, 2016 at 6:00 PM, Yiping Zhang <[email protected]> wrote:
> I think the work is mostly performed by the hypervisors. I had seen
> following during storage live migration in XenCenter:
>
> Highlight the primary storage for the departing cluster, then select the
> “Storage” tab on the right side panel. You should see disk volumes on that
> primary storage. The far right column is the “Virtual Machine” the disk
> belongs to.
>
> While the live storage migration is running, the migrating volume is shown
> as attached to a VM with the name “control domain for host xxx”, instead of
> the VM name it actually belongs to.
>
> To me, this is pretty convincing that Xen cluster is doing the migration.
>
> Yiping
>
> On 8/27/16, 5:10 AM, "Makrand" <[email protected]> wrote:
>
> Hello ilya,
>
> If I am not mistaken, while adding secondary storage NFS server ip and
> path
> is all one specifies in cloud-stack. Running df -h on ACS management
> server
> shows you secondary storage mounted there. Don't think hypervisor sees
> NFS
> (even if primary storage and NFS coming from same storage box). Plus,
> while
> doing activities like VM deploy and snapshot things always move from
> secondary to primary via SSVM.
>
> Have you actually seen any setup where you have verified this?
>
> @ cs user,
> When you're moving the volumes, are those attached to running VM? or
> those
> are just standalone orphan volumes?
>
>
>
> --
> Makrand
>
>
> On Thu, Aug 25, 2016 at 4:24 AM, ilya <[email protected]>
> wrote:
>
> > Not certain how Xen Storage Migration is implemented in 4.5.2
> >
> > I'd suspect legacy mode would be
> >
> > 1) copy disks from primary store to secondary NFS
> > 2) copy disks from secondary NFS to new primary store
> >
> > it might be slow... but if you have enough space - it should work...
> >
> > My understanding is that NFS is mounted directly on hypervisors. I'd
> ask
> > someone else to confirm though...
> >
> > On 8/24/16 7:20 AM, cs user 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!
> > >
> >
>
>
>
