[jira] [Commented] (VCL-844) Allow VMware VMs on standalone hosts to be migrated

["ASF subversion and git services (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/VCL-844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14507633#comment-14507633 ] 

ASF subversion and git services commented on VCL-844:
-----------------------------------------------------

Commit 1675454 from [~arkurth] in branch 'vcl/trunk'
[ https://svn.apache.org/r1675454 ]

VCL-844
Added OS.pm::get_os_perl_package. Added Windows.pm::_get_os_perl_package which is called by OS.pm::get_os_perl_package.

Updated OS.pm::get_os_type to return 'linux-ubuntu' if Ubuntu is detected rather than just 'linux'.

Added generate_ssh_key_files,generate_ssh_public_key_string, and create_ssh_public_key_file subroutines to OS.pm. These are used to facilitate host to host copying of files for VM migrations.

Added hibernate subroutine to Linux.pm, Ubuntu.pm, Windows.pm, and Version_5.pm.

Added Windows.pm::enable_hibernation.

Added is_process_running and is_display_manager_running to Linux.pm. These are used by Ubuntu.pm::hibernate to overcome issues which cause hibernation to fail.

Added subroutines to Ubuntu.pm to help overcome issues with hibernation:
* grubenv_unset_recordfail
* install_package
* _install_package_helper
* simulate_install_package
* apt_get_update
* fix_debconf_db

VCL-860
Updated Linux.pm::create_user to display a warning if any output line begins with 'useradd:'.

> 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)