[
https://issues.apache.org/jira/browse/VCL-844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14530598#comment-14530598
]
ASF subversion and git services commented on VCL-844:
-----------------------------------------------------
Commit 1677997 from [~arkurth] in branch 'vcl/trunk'
[ https://svn.apache.org/r1677997 ]
VCL-844
Reworked much of VMware.pm::migrat_vm to overcome issues with VMs which use
dedicated vmdk files - mainly for server requests.
Added optional type argument to OS.pm::find_files and
vSphere_SDK.pm::find_files.
Moved recently created SSH key subroutines from OS.pm to Linux.pm. They do not
work as-is on Windows. Reworked new SSH subroutines in VMware.pm. Most of this
code has been generalized and now exists in Linux.pm.
Added VMware.pm::add_ssh_host_key_to_known_hosts. SSH/SCP would hang on host to
host operations without any warning. This should allow host-host communication
to work without any manual changes.
Added caching to VIM_SSH.pm::_get_vm_id. This subroutine was inefficiently
being called numerous times for basic operations such as register_vm. The
cached VM ID is deleted when a VM is unregistered.
Updated vSphere_SDK.pm::initialize to attempt to load VIExt (vSphere SDK) after
checking if vmprofile username and password are defined. If not defined,
initialize returns immediately. This prevents unnecessary warnings from
appearing in vcld.log.
Added code to vSphere_SDK.pm::initialize to attempt to use the result of
determine_remote_connection_target.
Added vSphere_SDK.pm::get_vm_virtual_disk_file_paths to match VIM_SSH.pm. This
is now used in VMware.pm::delete_vm. Reworked delete_vm. It was not deleting
the directory containing the .vmdk for server reservations under some
circumstances.
Renamed VMware.pm::_get_vmx_file_path_computer_name to
_get_file_path_computer_name. Updated it to attempt to determine a computer
name from any path, not just a .vmx file path. This allows a VM's working
directory path to be passed to it. Updated VMware.pm::is_vmdk_directory_shared
to call _get_file_path_computer_name as an extra security check.
VCL-853
Updated vSphere_SDK.pm::_get_resource_pool_view to return the root pool if a
pool isn't configured in the VM profile and multiple pools are found on this
host.
> 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)
