[pve-devel] vm_copy : running vm copy for proxmox 3.0 ?

[Michael Rasmussen]

On Thu, 02 May 2013 10:58:28 +0200 (CEST)
Alexandre DERUMIER <aderumier at odiso.com> wrote:

> 
> The only thing need to be improved, is if the target storage is slower than source storage
> the drive-mirror can run indefinility,retrying again and again new block write.
> so currently the code make an optionnal vm pause to handle this case.
> But maybe we can use qmp block_set_io_throttle to limit the write on the source vm.
> 
Slower as in absolute speed or slower as in slow due to high load?
Both scenarios gives the same outcome.

I will make some experiment with 'block_set_io_throttle'. Is there any
best practice for setting the value of 'block_set_io_throttle'?

> I think that Michael Rasmussen have this problem, so maybe he can help us to test.
> I don't have a slow target storage to test ;)
> 
The only time I see this issue is if target is slower than source and
target is NFS and it is a live migration situation. iSCSI seems to be
more robust and generally handles migrations better than NFS.

-- 
Hilsen/Regards
Michael Rasmussen

Get my public GnuPG keys:
michael <at> rasmussen <dot> cc
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
mir <at> datanom <dot> net
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
mir <at> miras <dot> org
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917
--------------------------------------------------------------
Linux!  Guerrilla UNIX Development     Venimus, Vidimus, Dolavimus.
(By mah at ka4ybr.com, Mark A. Horton KA4YBR)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.proxmox.com/pipermail/pve-devel/attachments/20130502/fd827301/attachment.sig>