You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Alex Huang <Al...@citrix.com> on 2013/04/04 21:16:09 UTC
RE: [DISCUSS] Enabling storage xenmotion on xenserver 6.1
Devdeep,
I was looking at this. A few comments.
- On open issues 3: It makes more sense to create a new response object for your use. HostResponse really should be for listing hosts. Cramming a storagemigraterequired flag in there makes it weird for other APIs. Others may modify your response to add more statistics for the admin user to make better decisions and with this being in the HostResponse, then any such information would be pushed in there, making it unnatural for other apis which just needs the host. In fact, I would even call the API something other than listHostForMigration. The word list in ACS holds the general connotation that it is an db operations whereas here you're actually doing filtering for a certain operation. I think we should start a new convention in the api to say it's findHostsForMigration.
- The above will invalidate open question #4.
- The same goes for open question #5.
- I apologize for this. I think we discussed this before but I've forgotten. Why a separate api for migrateVmWithVolume? Why not just use the migrateVm command?
Thanks.
--Alex
> -----Original Message-----
> From: Devdeep Singh [mailto:devdeep.singh@citrix.com]
> Sent: Monday, March 18, 2013 7:50 AM
> To: cloudstack-dev@incubator.apache.org
> Subject: RE: [DISCUSS] Enabling storage xenmotion on xenserver 6.1
>
> 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+St
> > > > or
> > > > ag
> > > > e+
> > > > > XenMotion+for+XenServer. I'll keep updating it based on
> > > > > XenMotion+for+discussion 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
RE: [DISCUSS] Enabling storage xenmotion on xenserver 6.1
Posted by Devdeep Singh <de...@citrix.com>.
Hi Alex,
Thanks for looking at the changes.
1. I'll make the changes to have a separate response object for finding hosts and storage pools for migration. I'll also rename the apis to be called as findHostsForMigration and findStoragePoolsForMigration.
2. Why a separate api for migrating a vm with its volumes? We want the admin to be aware of the fact that he is migrating a vm with its volumes. The api takes hostid as a required parameter and migrateto as an optional parameter. 'Hostid' specifies the host to which a virtual machine should be migrated and 'migrateto' gives the volume to storage pool mapping for each volume of the vm. If 'migrateto' parameter isn't specified cloudstack tries to find an appropriate storage pool for each volume on the destination host.
If we use the migrateVm api, it may happen that by just giving the hostid parameter, the vm would get migrated along with its volumes and the admin isn't aware of it. Another option would be to have an optional parameter in the migrateVm api itself, e.g. migrateVolume, which has to be 'true' for a vm to be migrated with its volumes. But I felt having a separate api for this would be a cleaner approach.
Regards,
Devdeep
> -----Original Message-----
> From: Alex Huang [mailto:Alex.Huang@citrix.com]
> Sent: Friday, April 05, 2013 12:46 AM
> To: cloudstack-dev@incubator.apache.org
> Subject: RE: [DISCUSS] Enabling storage xenmotion on xenserver 6.1
>
> Devdeep,
>
> I was looking at this. A few comments.
>
> - On open issues 3: It makes more sense to create a new response object for
> your use. HostResponse really should be for listing hosts. Cramming a
> storagemigraterequired flag in there makes it weird for other APIs. Others
> may modify your response to add more statistics for the admin user to make
> better decisions and with this being in the HostResponse, then any such
> information would be pushed in there, making it unnatural for other apis
> which just needs the host. In fact, I would even call the API something other
> than listHostForMigration. The word list in ACS holds the general connotation
> that it is an db operations whereas here you're actually doing filtering for a
> certain operation. I think we should start a new convention in the api to say
> it's findHostsForMigration.
> - The above will invalidate open question #4.
> - The same goes for open question #5.
> - I apologize for this. I think we discussed this before but I've forgotten. Why
> a separate api for migrateVmWithVolume? Why not just use the migrateVm
> command?
>
> Thanks.
>
> --Alex
>
> > -----Original Message-----
> > From: Devdeep Singh [mailto:devdeep.singh@citrix.com]
> > Sent: Monday, March 18, 2013 7:50 AM
> > To: cloudstack-dev@incubator.apache.org
> > Subject: RE: [DISCUSS] Enabling storage xenmotion on xenserver 6.1
> >
> > 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+
> > > > > St
> > > > > or
> > > > > ag
> > > > > e+
> > > > > > XenMotion+for+XenServer. I'll keep updating it based on
> > > > > > XenMotion+for+discussion 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