incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Devdeep Singh <devdeep.si...@citrix.com>
Subject RE: [DISCUSS] Enabling storage xenmotion on xenserver 6.1
Date Mon, 18 Mar 2013 14:49:54 GMT
Hi,

I have been committing the changes related to storage motion for xenserver here https://github.com/devdeep/cloudstack/commits/sm.
I am still working on the unit tests. I'll put the changes up for review on review-board once
that is done. Please take a look at them and let me know your comments.

Regards,
Devdeep

> -----Original Message-----
> From: Devdeep Singh [mailto:devdeep.singh@citrix.com]
> Sent: Wednesday, January 16, 2013 7:24 PM
> To: cloudstack-dev@incubator.apache.org
> Subject: RE: [DISCUSS] Enabling storage xenmotion on xenserver 6.1
> 
> Hi Alex,
> 
> Please see inline.
> 
> Regards,
> Devdeep
> 
> > -----Original Message-----
> > From: Alex Huang [mailto:Alex.Huang@citrix.com]
> > Sent: Wednesday, January 16, 2013 5:47 AM
> > To: cloudstack-dev@incubator.apache.org
> > Subject: RE: [DISCUSS] Enabling storage xenmotion on xenserver 6.1
> >
> > Devdeep,
> >
> > I read the FS and have the following questions.
> >
> > - My understanding is that XenServer implements XenMotion by using
> > snapshots and that CloudStack's snapshots can interfere with this process.
> > This understanding might be old.  Can you confirm that this is not the
> > case?  If it is the case, how do you plan on dealing with that?
> [Devdeep] I tried storage xenmotion on a vm whose root disk had a snapshot
> taken. Storage xenmotion worked, but the reference to the snapshot on the
> volume wasn't preserved after the operation. I need to a look more into how
> this will affect the snapshot functionality of cloudstack.
> 
> > - I like to see exactly the API flow someone should execute this with.
> > I had one question that remains unanswered which is are we planning to
> > retrieve  a list of available hosts and storage pools to migrate to.
> > From the listHosts API that seems to be the case but what if it is only storage
> pool migration?
> [Devdeep] My thinking was to just update the lisHosts api to also give a list of
> hosts to which a vm can be migrated. If it is only storage pool migration than
> the admin has to specify the storage pool id in migrateVirtualMachine call and
> the virtual disks of the vm will be live migrated using xenmotion. Should we
> also provide an api for listing storage pools available for storage motion? Now
> that I think again about it, it does make more sense.
> 
> > - Are we planning to add APIs to storagepool allocator to make the
> > selection of storage pool portion work?  Is the current API enough?  I
> > see a flow for the actual migration but I don't see a flow for selecting what to
> migrate to.
> [Devdeep] I'll update the FS to include information on how selection for a
> storage pool is made.
> 
> > - Currently preparation on the destination host to migrate is done by
> > management server, in the flow in the FS, it is now being done by the
> > source agent.  What's the pros/cons of this change? I see that as an
> > open issue on your spec and I think if we can keep the hosts from
> > establishing contact with each other it will be best.
> [Devdeep] The current preparation (PrepareForMigrationCommand) is also
> applicable for storage xenmotion. TFor storage xenmotion there are a set of
> three apis that need to be called; migrateReceive (on dest), assertForMigrate
> (on src) and migrateSend (on src). The information returned by
> migrateReceive needs to be passed as a parameter in migrateSend.
> Additionally, the session created for migrateReceive should remain valid till
> the time storage migration completes. Is there a way to ensure this? If so, we
> can avoid hosts from establishing contact with each other.
> 
> > - I like to see the full API speced out.
> [Devdeep] I'll update the FS with more details.
> >
> > I also like to see Hari's question answered.  Can we provide this with
> > VmWare as well?
> [Devdeep] Sateesh was going to look at Storage vMotion for VmWare. I'll ask
> him to update on it.
> 
> >
> > --Alex
> >
> > > -----Original Message-----
> > > From: Devdeep Singh [mailto:devdeep.singh@citrix.com]
> > > Sent: Tuesday, January 08, 2013 1:58 AM
> > > To: cloudstack-dev@incubator.apache.org
> > > Subject: RE: [DISCUSS] Enabling storage xenmotion on xenserver 6.1
> > >
> > > Hi Swamy,
> > >
> > > In the following scenario when a VM has disks in different
> > > repositories, all the virtual disks of the VM will be moved to the
> > > same
> > destination repository.
> > > Moving individual disks of the VM to different repositories can be
> > > done, but it'll involve taking inputs from the user as to which disk
> > > should be moved to which repository. What do you think, should this
> > > option
> > be also provided?
> > >
> > > Regards,
> > > Devdeep
> > >
> > > > -----Original Message-----
> > > > From: Venkata SwamyBabu Budumuru
> > > > [mailto:venkataswamybabu.budumuru@citrix.com]
> > > > Sent: Thursday, December 27, 2012 5:42 PM
> > > > To: cloudstack-dev@incubator.apache.org
> > > > Subject: RE: [DISCUSS] Enabling storage xenmotion on xenserver 6.1
> > > >
> > > > Hi Devdeep,
> > > >
> > > > Does this also cover the following use case ?
> > > >
> > > > VM1	=> 	ROOT	(Storage Repository 1)
> > > > 	=>	DATA-1	(Storage Repository 2)
> > > >
> > > > Can I migrate DATA-1 vdi alone to a different repository? Or Is
> > > > this feature allowing the whole VM (including ROOT and DATA-1) to
> > > > same destination repository?
> > > >
> > > > Thanks,
> > > > SWAMY
> > > > -----Original Message-----
> > > > From: Hari Kannan [mailto:hari.kannan@citrix.com]
> > > > Sent: Thursday, December 27, 2012 2:18 AM
> > > > To: cloudstack-dev@incubator.apache.org
> > > > Subject: RE: [DISCUSS] Enabling storage xenmotion on xenserver 6.1
> > > >
> > > > Hi Devdeep,
> > > >
> > > > Should this discussion be expanded to cover VMware storage
> > > > migration or
> > > a
> > > > different discussion - I wish to see how we can add vSphere as a
> > > > supported platform for this feature..
> > > >
> > > > Hari
> > > >
> > > > -----Original Message-----
> > > > From: Devdeep Singh [mailto:devdeep.singh@citrix.com]
> > > > Sent: Wednesday, December 26, 2012 4:44 AM
> > > > To: cloudstack-dev@incubator.apache.org
> > > > Subject: RE: [DISCUSS] Enabling storage xenmotion on xenserver 6.1
> > > >
> > > > I have created an initial draft of the FS here
> > > >
> > > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Enabling+Stor
> > > ag
> > > e+
> > > > XenMotion+for+XenServer. I'll keep updating it based on discussion
> > > > XenMotion+for+and
> > > > comments.
> > > >
> > > > Regards,
> > > > Devdeep
> > > >
> > > > > -----Original Message-----
> > > > > From: Devdeep Singh [mailto:devdeep.singh@citrix.com]
> > > > > Sent: Tuesday, December 18, 2012 2:10 PM
> > > > > To: cloudstack-dev@incubator.apache.org
> > > > > Subject: [DISCUSS] Enabling storage xenmotion on xenserver 6.1
> > > > >
> > > > > Hi,
> > > > >
> > > > > XenServer introduced support for Storage XenMotion in the latest
> > > > > version (6.1). Storage XenMotion allows VMs to be moved from one
> > > > > host to another, where the VMs are not located on storage shared
> > > > > between the two hosts. It provides the option to live migrate a
> > > > > VM's disks along with the VM itself. It is now possible to
> > > > > migrate a VM from one resource pool to another, or to migrate a
> > > > > VM whose disks are on local storage, or even to migrate a VM's
> > > > > disks from one storage repository to another, all while the VM is
> running.
> > > > > More information on Storage
> > > > XenMotion can be found at [1].
> > > > >
> > > > > I have filed a jira request [2] to track this feature. I plan to
> > > > > extend the migrate vm cloudstack api call to allow migration of
> > > > > instances across clusters. Do let me know your comments.
> > > > >
> > > > > [1] http://blogs.citrix.com/2012/08/24/storage_xenmotion/
> > > > > [2] https://issues.apache.org/jira/browse/CLOUDSTACK-659
> > > > >
> > > > > Regards,
> > > > > Devdeep

Mime
View raw message