[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