virsh list authentication

Latest response

I am trying out some of the command line virsh and virt- commands on a RHEV host that contains KVM guests under RHEV 3.0 beta 4.   I am finding some of the command like virt-list-filesystems to be very nice.

 

But, "virsh list" asks for authentication user and password.   Does anyone know what user it is looking for?

 

Here is some output:

 

# virsh list
Please enter your authentication name: admin
Please enter your password:
error: Failed to reconnect to the hypervisor
error: no valid connection
error: authentication failed: authentication failed

# virsh list
Please enter your authentication name: root
Please enter your password:
error: Failed to reconnect to the hypervisor
error: no valid connection
error: authentication failed: authentication failed
 

Responses

When VDSM is managing a node libvirt is set to allow readonly mode (eg virsh --readonly list) any commands that require write access are locked down.

 

The virt-* commands you mentioned come from libguestfs, which isn't integrated with RHEV yet.

 

Hi,

 

I have gained access by creating a user on each RHEV server:

 

 

saslpasswd2 -a libvirt username

 

And then login with it.

 

Alisson.

YES. IT WORKS!!!!

Also successfully issued 'sysrq' using the magic key combo from the HOST.

Lifesaver. Thanks!!

"virsh start rh5-guest"

When a KVM guest is not running, how can I start it using the command line?

 

Just recently, during Hurricane Isaac, the RHEV-M machine was not available because of a 6-day power outage.   The remote RHEV host server was running fine, as well as the KVM guests.  If I need to start/stop KVM guests on RHEV without RHEV-M available, it would be great to be able to use virsh commands in more than readonly mode.

 

Is this possible?  Is there a plan to provide command line access to virsh under VDSM?

 

Paul

Since RHEV hosts are managed by VDSM, that in turn uses some parts of the libvirt functionality, you should be using VDSM's command line tool - vdsClient.

 

To run a VM, you need to run vdsClient -a 0 create <params>

 

virsh will not be able to power a VM on anyway, because the hosts do not hold VM XML definitions. To really protect against RHEV-M outages you need to secure your RHEV-M - set it up in HA mode and/or keep a local DR backup

Dan,

 

thanks for the info.   HA will not help if there is no electricity.   I will work on a remote DR backup of the RHEV-M machine.  I am not sure how to keep a remote RHEV-M machine current.   rsync will probably mangle the postgres database.

 

As for vdsClient, I would be very pleased if I could use it.   I have not been able to get the simplest vdsClient commands to work.   I get timeout on list table:

 

# vdsClient 0   list table
Traceback (most recent call last):
  File "/usr/share/vdsm/vdsClient.py", line 1987, in <module>
    code, message = commands[command][0](commandArgs)
  File "/usr/share/vdsm/vdsClient.py", line 185, in do_list
    for s in self.s.getAllVmStats()['statsList']:
  File "/usr/lib64/python2.6/xmlrpclib.py", line 1199, in __call__
    return self.__send(self.__name, args)
  File "/usr/lib64/python2.6/xmlrpclib.py", line 1489, in __request
    verbose=self.__verbose
  File "/usr/lib64/python2.6/xmlrpclib.py", line 1235, in request
    self.send_content(h, request_body)
  File "/usr/lib64/python2.6/xmlrpclib.py", line 1349, in send_content
    connection.endheaders()
  File "/usr/lib64/python2.6/httplib.py", line 908, in endheaders
    self._send_output()
  File "/usr/lib64/python2.6/httplib.py", line 780, in _send_output
    self.send(msg)
  File "/usr/lib64/python2.6/httplib.py", line 739, in send
    self.connect()
  File "/usr/lib64/python2.6/httplib.py", line 720, in connect
    self.timeout)
  File "/usr/lib64/python2.6/socket.py", line 567, in create_connection
    raise error, msg
error: [Errno 110] Connection timed out
 

Thats because I had a typo

 

The syntax is vdsClient -s 0 <command> <params>

-s stands for "secure", as vdsm used ssl to encrypt connections, but if you disable ssl, you can lose the "-s" and 0 stands for localhost (you can enter another hosts' IP here)

Dan,

your typo did not bother me.   I read through "vdsClient -h" and have tried many different command arguments.   It always returns timeout after about 30 seconds.   iptables does not appear to be blocking:

 

Chain INPUT (policy DROP)
target     prot opt source               destination         
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED
ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0           
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:54321
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:16514
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:22
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           multiport dports 5634:6166
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           multiport dports 49152:49216
ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0           udp dpt:161
ACCEPT     all  --  50.58.28.176/28      0.0.0.0/0           
ACCEPT     all  --  72.249.6.128/28      0.0.0.0/0           
ACCEPT     all  --  172.16.0.0/12        0.0.0.0/0           
ACCEPT     all  --  192.168.168.0/24     0.0.0.0/0           
ACCEPT     all  --  10.0.0.0/8           0.0.0.0/0           
REJECT     all  --  0.0.0.0/0            0.0.0.0/0           reject-with icmp-host-prohibited

Chain FORWARD (policy DROP)
target     prot opt source               destination         
REJECT     all  --  0.0.0.0/0            0.0.0.0/0           PHYSDEV match ! --physdev-is-bridged reject-with icmp-host-prohibited

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination   

I just saw that you didn't use "-s" in the previous post. Anyway, is vdsmd started on the host?

yes.

 

# chkconfig --list vdsmd
vdsmd              0:off    1:off    2:on    3:on    4:on    5:on    6:off
# service vdsmd status
VDS daemon server is running
# netstat -an |grep 54321
tcp        0      0 10.249.6.135:54321          0.0.0.0:*                   LISTEN      
 

I have these 2 rpms installed.   Do I need vdsm-reg also>

 

# rpm -qa |grep vds
vdsm-cli-4.9-113.3.el6_3.x86_64
vdsm-4.9-113.3.el6_3.x86_64
# yum search vdsm
Loaded plugins: dellsysid, product-id, refresh-packagekit, rhnplugin, security
dell-omsa-indep                                          | 1.9 kB     00:00     
dell-omsa-specific                                       | 1.9 kB     00:00     
rhel-x86_64-rhev-mgmt-agent-6                            | 1.6 kB     00:00     
rhel-x86_64-rhev-mgmt-agent-6/primary                    | 8.7 kB     00:00     
rhel-x86_64-rhev-mgmt-agent-6                                             40/40
rhel-x86_64-server-6                                     | 1.8 kB     00:00     
rhel-x86_64-server-6/primary                             | 9.9 MB     00:02     
rhel-x86_64-server-6                                                  8436/8436
============================== N/S Matched: vdsm ===============================
vdsm-cli.x86_64 : VDSM command line interface
vdsm-hook-vhostmd.x86_64 : VDSM hook set for interaction with vhostmd
vdsm-reg.x86_64 : VDSM registration package
vdsm.x86_64 : Virtual Desktop Server Manager
 

No, there is no need for vdsm-reg, it's only used for RHEV-H. 

 

Lets try this again, run `vdsClient -s 0 list` and if that fails, we'll need to look in the vdsm.log file

Dan,

 

below is the command output.   How do I attach a file to this group?    I have 450 lines of vdsm.log and would not want to muddy this with so much dump.

 

Paul

http://pastebin.com/e0g2a1bD

 

# vdsClient -s  0 list
Traceback (most recent call last):
  File "/usr/share/vdsm/vdsClient.py", line 1987, in <module>
    code, message = commands[command][0](commandArgs)
  File "/usr/share/vdsm/vdsClient.py", line 188, in do_list
    response = self.s.list(True)
  File "/usr/lib64/python2.6/xmlrpclib.py", line 1199, in __call__
    return self.__send(self.__name, args)
  File "/usr/lib64/python2.6/xmlrpclib.py", line 1489, in __request
    verbose=self.__verbose
  File "/usr/lib64/python2.6/site-packages/M2Crypto/m2xmlrpclib.py", line 49, in request
    h.endheaders()
  File "/usr/lib64/python2.6/httplib.py", line 908, in endheaders
    self._send_output()
  File "/usr/lib64/python2.6/httplib.py", line 780, in _send_output
    self.send(msg)
  File "/usr/lib64/python2.6/httplib.py", line 739, in send
    self.connect()
  File "/usr/lib64/python2.6/site-packages/M2Crypto/httpslib.py", line 73, in connect
    raise error
error: [Errno 110] Connection timed out
 

Hi Paul,

 

sorry to have kept you waiting, but it looks like more in-depth investigation will be required. Can you please open a support case for this issue? Something is definitely wrong with the host, shouldn't be doing that.

 

Dan

It has been weeks, but I have a resolution after working a support case.

 

My situation is that the RHEL host is inside a NAT firewall.   That means there is an external IP address known to the RHEV-M host, and the internal 10.x IP address.

 

/etc/vdsm/vdsm.conf defaults to listening for ssl connections to the internal 10.x IP address.   That works fine throught the NAT translation, but when accessing from inside, the vdsmd is not listening at that IP address.

 

# netstat -lntp |grep 54321

tcp 0 0 10.249.6.135:54321 0.0.0.0:* LISTEN 40164/python

 

Using vdsClient with ssl, I get a mismatch on the certificate.

 

# vdsClient -s 10.249.6.135 list

Traceback (most recent call last):

....

WrongHost: Peer certificate commonName does not match host, expected 10.249.6.135, got 72.249.6.135

 

To overcome these obstacles, I made 2 changes.   First, change vdsmd to listen on any IP address, and restart vdsmd

 

change /etc/vdsm/vdsm.conf
management_ip=0.0.0.0

 

Second, add the external IP address to the NIC as a secondary IP:

 

ip addr add 72.249.6.135/24 dev rhevm

 

Now both these vdsClient commands work from inside:

# vdsClient -s 0 list table

# vdsClient -s 72.249.6.135 list table

 

Also, I created /sbin/ifup-local to add the ip address on boot.

Try this out: Name: vdsm@rhevh Password: shibboleth

The recommendation is to use the virsh readonly mode: 'virsh -r' . However some diagnostics still require using virsh without the readonly flag. Tor those:

Newer RHV (4.x) versions use vdsm@ovirt :

sasldblistusers2 -f /etc/libvirt/passwd.db

vdsm@ovirt: userPassword

Password remains shibboleth .

This keeps coming up as the answer when I google for this very problem. I recently found another comment that might actually be more accurate:

virsh -c qemu:///system?authfile=/etc/ovirt-hosted-engine/virsh_auth.conf

(ref: https://lists.ovirt.org/pipermail/users/2017-January/079157.html)