Feature proposal/discussion -- create API command that "migrates" a hosts from a cluster to another

[GabrielBrascher]

ISSUE TYPE

• Feature Idea

COMPONENT NAME

API

CLOUDSTACK VERSION

4.17

CONFIGURATION

KVM

OS / ENVIRONMENT

N/A

SUMMARY

CloudStack does not allow to migrate hosts from clusters. This Issue raises the feature idea of migrating hosts between clusters. In KVM at least this is quite easy to be done. Basically, it can be done by changing the agent.properties and updating a few tables in the DB.

At first, I would propose creating such an API command only for KVM. As far as I know, XenServer & VMware aren't as simple. Quite a long time since I played with Xen or VMware, so I am not raising them here. But anyone interested in discussing raising it. feel free.

The idea is that such a host should be placed into maintenance, making sure that no VMs will be running. If the host is in Maintenance, then the API command would run the needed changes in order to have the host available at other cluster. This would require Admins to ensure that the shared storage pool is available at the zone-wide level.

[nvazquez]

Thanks @GabrielBrascher for the proposal. IMO this would not feasible for Vmware or Xen, they would require to be externally handled by the administrator on the hypervisor side. For example on Vmware, putting the host on maintenance, unmounting the datastores on the host which belong to the 'old' cluster and mounting the datastores from the 'new' cluster, check portgroups, would need to be handled externally. However, I do think it is a good idea for KVM - should this API have any prerequisite besides the host being on maintenance? Opinions? @rohityadavcloud @borisstoyanov @sureshanaparti @andrijapanicsb @DaanHoogland

[andrijapanicsb]

While I appreciate that the feature might be interesting for KVM, I don't think it's worth the effort since other hypervisors can't be migrated and for KVM a simpe DB changes will do.

[mlsorensen]

Would this basically be an automated shortcut for removing and adding the host, or is there a benefit of actually moving it, like retaining the host's ID or history?

[DaanHoogland]

Added bonus of that

Would this basically be an automated shortcut for removing and adding the host, or is there a benefit of actually moving it, like retaining the host's ID or history?

is that the comments/annotations on the host would be retained. I like the idea but fear this will be worked on more than it will be used. In a datacenter a cluster would typically be organised around which hosts sit together in the top, middle or bottom of which rack/pod. a re-clustering would mean physical moving usually and the removing/adding would make more sense. Of course you might have different experiences @GabrielBrascher @mlsorensen ... ?

[GabrielBrascher]

@nvazquez @andrijapanicsb that's true, it would be focused specifically on KVM. Definitelly not a good idea for VMware and XenServer.

@mlsorensen indeed, it is a shortcut for removing and adding a host from CloudStack. Also, I don't think it would cause downtime for VMs, as long as they are allocated either on local storage and/or zone-wide shared pools. Host IP addresses, connected pools, and guest networks could remain the same in such cases.

@DaanHoogland this rarely happens. But decided to open a discussion as I've seen it happen. It is quite fun to move hosts around CloudStack "logical" clusters.

To "move" a host between clusters it is needed just a few changes in DB and host's agent.properties. It is not hard to do it "manually" so I'm not sure if it justifies an API call. But I rather first hear what you guys have in mind and if this could maybe add some interesting dynamic for operating KVM-based clusters.

Keep in mind that a Pod is a "DC Rack" that contains one or multiple "clusters". In that sense, KVM hosts can easily be changed from clusters when residing in the same Pod as they are using the same switch (L2 network). Therefore, no networking nor pool changes are required in such cases, neither unplugging/plugging hosts in different racks.

[DaanHoogland]

@DaanHoogland this rarely happens. But decided to open a discussion as I've seen it happen. It is quite fun to move hosts around CloudStack "logical" clusters.

To "move" a host between clusters it is needed just a few changes in DB and host's agent.properties. It is not hard to do it "manually" so I'm not sure if it justifies an API call. But I rather first hear what you guys have in mind and if this could maybe add some interesting dynamic for operating KVM-based clusters.

Keep in mind that a Pod is a "DC Rack" that contains one or multiple "clusters". In that sense, KVM hosts can easily be changed from clusters when residing in the same Pod as they are using the same switch (L2 network). Therefore, no networking nor pool changes are required in such cases, neither unplugging/plugging hosts in different racks.

Yes, so that would limit changing clusters within a pod, would it? As said and though I like the idea from a logical point of view, I fear it will not be used as much as it would seem at first sight.

If however it is persistently done manually it does justify an API endpoint as manual DB manipulation should be avoided.

[GabrielBrascher]

Agree, let's not proceed with creating a new API command then. Eventually, if this becomes a common case, then it would make sense to consider an API endpoint.

[GabrielBrascher]

Closed for now. Thanks for participating in this discussion :) Please let me know if this issue makes sense or if any of you see interesting things that we could do in this context.