[libvirt-users] First & long question
Hello everybody! /(First I need to apologize becase I mussunderstood the prupose of libvirt-list and I sent this mail there instead of this list)/ I would like to introduce myself, as this is my first contact with libvirt mailing list (although I've been reading quite a lot of documentation). My name is Joaquim Barrera, from Barcelona, Catalonia. I am a computer engineer and recently I joined a research group here in the university. My task is related to VM migration and management, and since then (a couple of months) I've been trying to figure some things up. Now I need to go one step forward, and I would like to set up a nice dev environment to try some modifications we want to make to libvirt, such as new API or migration-related-stuff. Although I am familiar with linux environrment and programming, I am not really quite familiar with this kind of, may I say, professional development, and there are some issues I need to solve before start writting code. Some of this issues you'll find not relevant or newbie stuff, but I assure you I tried lots of times before coming here. :-) Here is what I got following the instructions in http://libvirt.org/compiling.html $ ./autogen.sh --system $ make 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/) 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/ 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... :_( The final comment is, am I following the right direction to be able to develop something with libvirt? :_) Ok, that's all for now, thank you A LOT for your time. Joaquim.
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
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
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
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
On 16/12/13 11:19, Ján Tomko wrote: 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. :-)
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 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
On 16/12/13 11:19, Ján Tomko wrote: 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
On 16/12/13 17:41, Eric Blake wrote:
On 12/16/2013 08:53 AM, Joaquim Barrera wrote:
[please don't top-post on technical lists]
Sorry about that.
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).
All right, I tried qemu+libssh2 but got more problems. Finally I went for passwordless login and at some point I'll try to handle it again. My main issue here was actually the reason why it works using standard virsh 1.1.1 but it does not with custom compiled 1.2.0, but I guess it's a matter of compiling options or some parameter I missed. Thanks again!
participants (3)
-
Eric Blake -
Joaquim Barrera -
Ján Tomko