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

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

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

VCL-844
Added Term::ANSIColor to install_perl_libs.pl. It is a standard Perl package 
but needs to be updated in order for some color features to work which are used 
in new vcld -setup code.

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

Reply via email to