How is the traffic different when using the tunnelled option rather than ssh without tunnelling? On Wed, Mar 23, 2016, 5:14 PM Michal Privoznik <mprivozn@redhat.com> wrote:> On 22.03.2016 10:28, nidhi d wrote: > > How is tunnelled option specified during migratiion different than an > > ordinary ssh connection specified as:- virsh migrate vmName > > qemu+ssh://user@remotesys/system? > > > > > > virsh migrate --tunelled ... > > Michal > >
On 23.03.2016 14:13, nidhi d wrote:> How is the traffic different when using the tunnelled option rather than > ssh without tunnelling?There are two migration streams here: 1) libvirt (used to transfer libvirt's internal state of domain onto the other side) 2) qemu (used to transfer qemu's internal state of domain onto the other side) specifying bare qemu+ssh:/// makes libvirt pack its stream into an ssh stream, but says nothing about qemu stream. Using tunnelling tells libvirt to encapsulate qemu migration stream into its own stream and thus into ssh stream too. Michal
I tried using tunnelled mode for vm migration, but migration failed with the error Permission denied(publickey,password):Connection reset by peer I have enabled passwordless ssh login at the destination. Also i am able to connect to the destination using using qemu+ssh. On Wed, Mar 23, 2016, 6:59 PM Michal Privoznik <mprivozn@redhat.com> wrote:> On 23.03.2016 14:13, nidhi d wrote: > > How is the traffic different when using the tunnelled option rather than > > ssh without tunnelling? > > There are two migration streams here: > > 1) libvirt (used to transfer libvirt's internal state of domain onto the > other side) > 2) qemu (used to transfer qemu's internal state of domain onto the other > side) > > specifying bare qemu+ssh:/// makes libvirt pack its stream into an ssh > stream, but says nothing about qemu stream. Using tunnelling tells > libvirt to encapsulate qemu migration stream into its own stream and > thus into ssh stream too. > > Michal >