4 a.m.
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.
4:19 a.m.
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
8:47 a.m.
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. :-)
9:53 a.m.
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(a)redhat.com
https://www.redhat.com/mailman/listinfo/libvirt-users
10:41 a.m.
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
11:50 a.m.
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!
3996
days inactive
3996
days old
5 comments
3 participants
participants (3)
-
Eric Blake -
Joaquim Barrera -
Ján Tomko