[pve-devel] qm migrate : do we really need a -online option ?

[Jean Weisbuch]

Le 24/08/2012 19:47, Rob wylde a écrit :
> Perhaps this could also be part of a global configuration ?
>
> On Fri, Aug 24, 2012 at 11:30 AM, Michael Rasmussen <mir at datanom.net 
> <mailto:mir at datanom.net>> wrote:
>
>     Sorry, should have been sent to the list.
>
>     On Fri, 24 Aug 2012 15:40:33 +0000
>     Dietmar Maurer <dietmar at proxmox.com <mailto:dietmar at proxmox.com>>
>     wrote:
>
>     >
>     > Well, I tried to provide the same options as openvz.
>     >
>     Maybe its just me that is confused, but:
>     1) A running CT can only be migrated using online migration?
>     2) A CT not running will use offline migration?
>
>     So what is point of give the user a choice when the choice is
>     given? (A
>     quote from Henry Ford: The customer can choose any color he likes as
>     long as i chooses black)
>
>
>     --
>     Hilsen/Regards
>     Michael Rasmussen
>
Online migration might be a bit longer and require more ressources 
(requires a memory snapshot and a transfert of that memory that an 
offline one don't) ; it could be interresting to do an offline migration 
in case you have a low bandwith connection between both hosts and that 
the CT is having a heavy memory usage.
Snapshoting and transferring that memory content would be longer than 
just stopping/restarting the CT and some applications wouldnt handle 
correctly the "timeout" induced by being frozen for more than few 
seconds rather than cleany stopped then restarted (would be a very rare 
case).


It could also be nice to have "advanced options" which would permit to 
exclude directories/files or at least specify rsync parameters (using 
for example --inplace is usually safe when moving a CT or putting a 
--bwlimit) or being able to set an ionice parameter either on the source 
or on the destination.

--
Regards,
Jean Weisbuch
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.proxmox.com/pipermail/pve-devel/attachments/20120824/207a8b0e/attachment.htm>