migration slow, disable encryption?
- Thread starter q16marvin
- Start date
hi,
seems not work, i add this line to datacenter.cfg, it was automaticly add to other cluster nodes. i reboot all nodes. but when i migrate i reach still not more than 45MB/s. the ssh or sshd process is still 100%:
Thx!
mhh my qemu is 1.4 so it should work or?
proxmox-ve-2.6.32: 3.1-114 (running kernel: 2.6.32-26-pve)
pve-manager: 3.1-24 (running version: 3.1-24/060bd5a6)
pve-kernel-2.6.32-19-pve: 2.6.32-93
pve-kernel-2.6.32-16-pve: 2.6.32-82
pve-kernel-2.6.32-26-pve: 2.6.32-114
lvm2: 2.02.98-pve4
clvm: 2.02.98-pve4
corosync-pve: 1.4.5-1
openais-pve: 1.1.4-3
libqb0: 0.11.1-2
redhat-cluster-pve: 3.2.0-2
resource-agents-pve: 3.9.2-4
fence-agents-pve: 4.0.0-2
pve-cluster: 3.0-8
qemu-server: 3.1-8
pve-firmware: 1.0-23
libpve-common-perl: 3.0-9
libpve-access-control: 3.0-8
libpve-storage-perl: 3.0-18
pve-libspice-server1: 0.12.4-2
vncterm: 1.1-6
vzctl: 4.0-1pve4
vzprocps: 2.0.11-2
vzquota: 3.1-2
pve-qemu-kvm: 1.4-17
ksm-control-daemon: 1.1-1
glusterfs-client: 3.4.1-1
Last edited:
Hi,
I have the same problem.
migration_unsecure: 1
seems not to work.
I took a look at the files:
/usr/share/perl5/PVE/QemuMigrate.pm
/usr/share/perl5PVE/QemuServer.pm
and for me it looks like the patch is applied.
also see here: http://pve.proxmox.com/wiki/Roadmap#Proxmox_VE_3.1
Any help is appreciate
Sven
I have the same problem.
migration_unsecure: 1
seems not to work.
I took a look at the files:
/usr/share/perl5/PVE/QemuMigrate.pm
/usr/share/perl5PVE/QemuServer.pm
and for me it looks like the patch is applied.
also see here: http://pve.proxmox.com/wiki/Roadmap#Proxmox_VE_3.1
Any help is appreciate
Sven
I think that this option only applies to live migration when it copies the RAM.
It does not apply to the rsync operation to copy a VM image file.
I know it works perfectly fine for speeding up the RAM copy when doing live migrations, I regurarly get over 500MB/sec on my Infiniband cluster.
It does not apply to the rsync operation to copy a VM image file.
I know it works perfectly fine for speeding up the RAM copy when doing live migrations, I regurarly get over 500MB/sec on my Infiniband cluster.
mhh okay, so there is no way to migrate (without live) from one node to other a little bit faster? we have no HA running, when i have to update node 1 i only want to move all kvm's to other node.
the problem is not ne "speed", much more is the high cpu load during this time, so other "running" kvm's on both nodes are getting extrem slow until unusable.
thx!
Erik
mhhh no one a idea? i have to migrate a 200GB kvm and it will need about 90 minutes
Yep migration is done over ssh so the bottle neck is going to be a single CPU core. I highly doubt its all CPU causing the bottle neck, if you are moving a 200GB image, my guess is that you are seeing slow downs due to lack of IO. Your best bet is to move over to central storage or some type of DRBD setup.
but i dont want to buy a seperate storage for only one migration?!?! why is it not possible to copy data between nodes without ssh?
As far as i know rsync needs ssh. Even without SSH you wont be getting much increase improvement due to 1g network. With a shared storage this issue can be easily addressed. If budget is tight or do not have enough spare parts laying around, all you need is a basic dual core pc with minimum 4gb ram with some hdds. Setup a FreeNAS system with NFS or iSCSI, then move all VMs there. This will eliminate long waits of migration. Within few minutes all VMs can be moved to a different node.
Sent from my ASUS Transformer Pad TF700T using Tapatalk
Sent from my ASUS Transformer Pad TF700T using Tapatalk
I agree, with a 10GB backend, I went from 5-10 minute migrations to 20-30 second migrations. Really appreciate the addition.
in german someone describe the problem:
http://geekparadise.de/2010/07/schlechte-performance-mit-ssh-rsync-daemon-beheben/
But i dont understand it realy
So i have read about something changing the encryption method like this:
/usr/bin/rsync --progress --sparse --whole-file /var/lib/vz/images/125/vm-125-disk-1.qcow2 root@192.168.200.32:/var/lib/vz/images/125/vm-125-disk-1.qcow2 -e "ssh -c arcfour"
when i run this manualy it works much better.
where did i have to change this?
I believe that Proxmox no longer forces a particular cipher.
So you should be able to simply edit the ssh client config to set the preferred cipher
edit /etc/ssh/ssh_config and add something like this:
The Ciphers line shoud contain all the ciphers you want to use in the order that you most prefer.
arcfour is not as secure as other ciphers, so you might want to not use Host *, instead you can specify the specific hosts this applies to.
So you should be able to simply edit the ssh client config to set the preferred cipher
edit /etc/ssh/ssh_config and add something like this:
Code:
Host *
Ciphers arcfour,blowfishThe Ciphers line shoud contain all the ciphers you want to use in the order that you most prefer.
arcfour is not as secure as other ciphers, so you might want to not use Host *, instead you can specify the specific hosts this applies to.
in german someone describe the problem:
http://geekparadise.de/2010/07/schlechte-performance-mit-ssh-rsync-daemon-beheben/
But i dont understand it realy
All this mentions is the usage of rsync in a way where you have the receiving end also run an rsync demon that accepts connections. This is because the problem mainly boils down to network basics: If you want to connect from Host A to Host B to transfer a file, you need a listening service on Host B that accepts connections. On a "normal" setup this almost always the sshd. So if you want to skip the use of ssh, you need a different demon on Host B... like the afore mentioned rsync demon.
Heres a randomly selected $searchengine hit describing the setup: http://www.jveweb.net/en/archives/2011/01/running-rsync-as-a-daemon.html