[pve-devel] vm_copy : running vm copy for proxmox 3.0 ?
Alexandre DERUMIER
aderumier at odiso.com
Thu May 2 18:34:10 CEST 2013
>>Slower as in absolute speed or slower as in slow due to high load?
>>Both scenarios gives the same outcome.
If the target can't write as fast as source (or network bandwith is too small), and that your source have a lot of writes during the copy for example.
>>I will make some experiment with 'block_set_io_throttle'. Is there any
>>best practice for setting the value of 'block_set_io_throttle'?
Maybe can we compute average source new writes (ios ? bandwith ?), or something like that, and decrease progressively the ios or bandwith.
I need to think about that a little more.
>>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.
I think it depend of the storage. I have done it with nfs4 on netapp storage without problem.
----- Mail original -----
De: "Michael Rasmussen" <mir at datanom.net>
À: "Alexandre DERUMIER" <aderumier at odiso.com>, "Dietmar Maurer" <dietmar at proxmox.com>, pve-devel at pve.proxmox.com
Envoyé: Jeudi 2 Mai 2013 17:29:31
Objet: Re: [pve-devel] vm_copy : running vm copy for proxmox 3.0 ?
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)
More information about the pve-devel
mailing list