On 16/12/13 11:19, Ján Tomko wrote:> On 12/16/2013 11:00 AM, Joaquim Barrera wrote: >> After make finishes I have compiled 1.2.0 libvirt in the source tree, and if I >> execute 'sudo ./run tools/virsh version' I get a this answer: >> >> /Compiled against library: libvirt 1.2.0// >> //Using library: libvirt 1.2.0// >> //Using API: QEMU 1.2.0// >> //Running hypervisor: QEMU 1.5.0/ >> >> (/note that now I need to run virsh with sudo, I don't know exactly why/) > When run as root, virsh connects to the system libvirt daemon by default (URI > qemu:///system). As a non-privileged user, qemu:///session is used and the > daemon is run as the user. > > See http://libvirt.org/uri.html#URI_qemuBased on this, if I execute regular 1.1.1 'virsh uri' as a non-root I would read qemu:///session, but instead I get qemu:///system in my computer.> >> So far, so good. I guess that, with --system flag, 1.2.0 custom libvirt uses >> config files from standard directories such as /etc/libvirt/libvirtd.conf, and >> if I used a custom directory instead, I would have to redefine my VMs, am I right? >> >> Problems come when I want to use custom 1.2.0 daemon. If I execute "sudo >> service libvirt-bin stop" followed by "./daemon/libvirtd -d", then custom >> virsh gives me this error: >> >> /error: failed to connect to the hypervisor// >> //error: no valid connection// >> //error: Failed to connect socket to '/var/run/libvirt/libvirt-sock': No such >> file or directory/ >> > You need to run the daemon as root if you want it to listen on > /var/run/libvirt/libvirt-sockGot it. Running both custom 1.2.0 daemon and virsh tool as root works like a charm. :-)> >> And I need to kill custom daemon and restart 1.1.1 libvirtd to recover from >> this. Any advice? >> >> Finally (sorry about this large mail), there is one thing that does bother me >> quite a lot. >> >> Using custom virsh, command history seems to vanish, as I press Arrow-UP and I >> get "^[[A" in the screen, instead of last command used. Tell me, please, that >> this is just some silly config I need to adjust... :_( >> > Do you have the develompent headers for readline installed? > > JanOk, I've been missing the -dev package... When I installed it and then made ./configure, I got 'READLINE_LIBS = -lreadline' which then enabled the history in my custom virsh. I don't know if this is related, but when I do a migrate command, it turns down the password I enter, as if it's wrong written (and I trued several times). I'll try to work through this. Thank you for your time. :-)
Excuse me for the duplicate anwer but I observed exactly what I was telling you. I execute "sudo ./run tools/virsh" and then: 'connect qemu+ssh://user@IP_ADDRESS:PORT/system' and it asks me the password. Everything goes right. 'migrate --verbose --persistent --copy-storage-inc VM1 qemu+ssh://user@IP_ADDRESS:PORT/system' and it asks me the password, but never gets it right. I allways get to the third attempt and get rejected. May it be related to something I wrote here before? Thanks! On 16/12/13 15:47, Joaquim Barrera wrote:> > On 16/12/13 11:19, Ján Tomko wrote: >> On 12/16/2013 11:00 AM, Joaquim Barrera wrote: >>> After make finishes I have compiled 1.2.0 libvirt in the source >>> tree, and if I >>> execute 'sudo ./run tools/virsh version' I get a this answer: >>> >>> /Compiled against library: libvirt 1.2.0// >>> //Using library: libvirt 1.2.0// >>> //Using API: QEMU 1.2.0// >>> //Running hypervisor: QEMU 1.5.0/ >>> >>> (/note that now I need to run virsh with sudo, I don't know exactly >>> why/) >> When run as root, virsh connects to the system libvirt daemon by >> default (URI >> qemu:///system). As a non-privileged user, qemu:///session is used >> and the >> daemon is run as the user. >> >> See http://libvirt.org/uri.html#URI_qemu > Based on this, if I execute regular 1.1.1 'virsh uri' as a non-root I > would read qemu:///session, but instead I get qemu:///system in my > computer. >> >>> So far, so good. I guess that, with --system flag, 1.2.0 custom >>> libvirt uses >>> config files from standard directories such as >>> /etc/libvirt/libvirtd.conf, and >>> if I used a custom directory instead, I would have to redefine my >>> VMs, am I right? >>> >>> Problems come when I want to use custom 1.2.0 daemon. If I execute >>> "sudo >>> service libvirt-bin stop" followed by "./daemon/libvirtd -d", then >>> custom >>> virsh gives me this error: >>> >>> /error: failed to connect to the hypervisor// >>> //error: no valid connection// >>> //error: Failed to connect socket to >>> '/var/run/libvirt/libvirt-sock': No such >>> file or directory/ >>> >> You need to run the daemon as root if you want it to listen on >> /var/run/libvirt/libvirt-sock > Got it. Running both custom 1.2.0 daemon and virsh tool as root works > like a charm. :-) >> >>> And I need to kill custom daemon and restart 1.1.1 libvirtd to >>> recover from >>> this. Any advice? >>> >>> Finally (sorry about this large mail), there is one thing that does >>> bother me >>> quite a lot. >>> >>> Using custom virsh, command history seems to vanish, as I press >>> Arrow-UP and I >>> get "^[[A" in the screen, instead of last command used. Tell me, >>> please, that >>> this is just some silly config I need to adjust... :_( >>> >> Do you have the develompent headers for readline installed? >> >> Jan > > Ok, I've been missing the -dev package... When I installed it and then > made ./configure, I got 'READLINE_LIBS = -lreadline' which then > enabled the history in my custom virsh. > > I don't know if this is related, but when I do a migrate command, it > turns down the password I enter, as if it's wrong written (and I trued > several times). I'll try to work through this. > > Thank you for your time. :-) > > _______________________________________________ > libvirt-users mailing list > libvirt-users@redhat.com > https://www.redhat.com/mailman/listinfo/libvirt-users > >
On 12/16/2013 08:53 AM, Joaquim Barrera wrote: [please don't top-post on technical lists]> Excuse me for the duplicate anwer but I observed exactly what I was > telling you. I execute "sudo ./run tools/virsh" and then:If you are running virsh as sudo, then you must remember that virsh is running under root, not you.> > 'connect qemu+ssh://user@IP_ADDRESS:PORT/system' and it asks me the > password. Everything goes right.Yes, for a single connection, remote password authentication over qemu+ssh works.> > 'migrate --verbose --persistent --copy-storage-inc VM1 > qemu+ssh://user@IP_ADDRESS:PORT/system' and it asks me the password, but > never gets it right. I allways get to the third attempt and get rejected.That's because the qemu+ssh URI has an inherent design limitation that it can only validate a single connection, but migration requires two connections. You can try qemu+libssh:// URIs instead, which is supposed to resolve the authentication issues by using libssh within virsh instead of an external call to ssh(1) (although I haven't tried it myself). Or you can set up passwordless login over ssh (such as by using ssh-copy-id) - but remember that you must set it up so that root can access user@IP_ADDRESS:PORT (since 'sudo virsh' is running as root, not you). -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org