[
https://issues.apache.org/jira/browse/VCL-844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14527235#comment-14527235
]
ASF subversion and git services commented on VCL-844:
-----------------------------------------------------
Commit 1677678 from [~arkurth] in branch 'vcl/trunk'
[ https://svn.apache.org/r1677678 ]
VCL-844
Updated utils.pm::get_vmhost_info to allow vmprofile.profilename to be used for
matching the $vmhost_identifier argument. The matching info is returned if the
argument exactly matches vmprofile.profilename when multiple rows are
retrieved. It had been returning null any time multiple rows were retrieved.
This allows a specific vmhost-vmprofile to be retrieved when multiple vmhost
entries exist for a computer.
> Allow VMware VMs on standalone hosts to be migrated
> ---------------------------------------------------
>
> Key: VCL-844
> URL: https://issues.apache.org/jira/browse/VCL-844
> Project: VCL
> Issue Type: New Feature
> Components: database, vcld (backend), web gui (frontend)
> Reporter: Andy Kurth
> Assignee: Andy Kurth
> Priority: Minor
>
> It is possible to do a _poor man's_ migration of a VM from one standalone
> VMware host to another without requiring enterprise vSphere licenses for the
> hosts or vCenter. This can even be accomplished on the free version of ESXi.
> This feature would be very helpful when a host which is running VMs for
> long-term reservations needs to be upgraded or taken out of service for some
> reason.
> I have been experimenting with some code for this. The migration process
> works as follows:
> * Gather information about the source VM.
> * Make sure the destination VM host has a copy of the master/parent .vmdk
> image. Copy it if necessary.
> * Take a snapshot of the VM. This causes it to start using a new, smaller
> delta .vmdk file.
> * Copy all files in the source VM's working directory to the destination,
> except the ones which are in use. This would include delta .vmdk files from
> previous snapshots.
> * Hibernate the VM.
> * Copy the files which were being used by the VM while powered on.
> * Update the VM's files on the destination VM host to contain the correct
> datastore paths for the destination host.
> * Resume/power on the destination VM.
> * Verify the destination VM is responding.
> * Remove the source VM.
> * Update computer.vmhostid.
> Because hibernation is used, the state of the VM is not lost as it would if
> the VM had to be shutdown and restarted. Regardless, it is important to
> minimize the amount of time the VM is hibernating. This is the reason for
> taking the snapshot. Before the migration, the VM's delta file contains all
> changes written to its virtual disk since the VM was loaded and is likely
> quite large. The snapshot causes the VM to start using a new delta file.
> The previous, large delta file can be copied to the destination while the
> source VM is still powered on.
> We will need how this will be controlled via the website and how the
> migration information will need to be presented in the database. We could
> add a new _migrate_ request state. The backend could would need to know the
> destination VM host ID.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
