Virtual Server Migration

From support-works
Revision as of 08:57, 10 April 2015 by Rickyf (talk | contribs) (Created page with "{{Template:Basic Cover |title=Virtual Server Migration |type=FAQ |htl=Y }} {{Template:Basic Status |status=Published |version=1.0 |authors=HTL QA |applicableto=Supportwor...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search



Status: Published
Version: 1.0
Authors: HTL QA
Applies to: Supportworks ESP Version 7.4.x

Virtual Server Migration

A number of virtualisation tools (such as VMware vMotion) exist that allow "live migration" of virtual servers, which means that (in theory, at least) the migration is performed without the server needing to be stopped/restarted and hence losing its connections. Hornbill does not provide technical support for migrating servers through vMotion or any other similar live-migration mechanisms. Such migration is possible, but you would do this at your own risk.

If you do decide to perform a live migration, you should ensure that the following requirements are met:

  • The system ID on the new host should be the same as that on the server to be migrated. This can be achieved by using the same static MAC address and (within Supportworks Version 7.4.x) setting the CPU flags within the Windows registry on the server to the same value as on the current host. The FAQ entitled Licensing Issues Resulting from System ID Changes indicates which registry entry to change.
  • Communications with databases should ideally be uninterrupted, but although live migration aims to do this, you cannot guarantee to totally rule out the necessity for server restarts. If the database (for example, SwSQL) is still local to the Supportworks services once migrated to the new VMware instance, then there is a good chance that server restarts will not be absolutely necessary. However, if the database is remote (for example, an MS SQL cluster), then a restart of the Supportworks services - all services except SwSQLServer - will always be required. (It is required because the ODBC pool of connections would no longer be valid).

After a migration, we nevertheless recommend that, in all circumstances, the services are restarted. Following the restarts, all clients will of course need to reconnect to the migrated server.