[
https://issues.apache.org/jira/browse/VCL-844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14507772#comment-14507772
]
ASF subversion and git services commented on VCL-844:
-----------------------------------------------------
Commit 1675483 from [~arkurth] in branch 'vcl/trunk'
[ https://svn.apache.org/r1675483 ]
VCL-844
Added subroutines to VMware.pm:
* get_vmx_url_base_directory_path
* get_vmx_intermediate_directory_path
* _get_datastore_url
* _get_url_path
* configure_vmhost_ssh_keys
* copy_vmhost_ssh_public_key_to_another_host
* copy_file_to_another_host
* setup_migrate_vm
* migrate_vm
* migrate_revert_source
Added subroutines to utils.pm:
* update_computer_vmhost_id.
* setup_get_hash_multiple_choice.
Updated Module.pm::new to call initialize on ManagementNode.pm objects even if
$SETUP_MODE is true.
Updated Module.pm::create_object to accept an additional argument which allows
arguments to be passed to the constructor of the object being created as well
as the DataStructure.pm object.
Updated Module.pm::create_vmhost_os_object to accept an argument specifying
which VM host to create an object for.
Updated DataStructure.pm to accept a vmhost_identifier argument rather than use
a vmhost_id argument.
Changed where cached data is stored from %ENV to $self in order to allow it to
work with multiple VMware.pm objects.
VCL-851
Added check to skip the attempt to use vSphere_SDK.pm if vmprofile.password is
not configured.
> 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)
