Thank you very much for your helpful reply . The error of my question 4 is solved after I stopping debug vdsm code, just using print log info instead. On Tue, Jul 26, 2016 at 12:46 PM, lifuqiong <lifuqiong(a)cncloudsec.com&gt; wrote: We use single port for both protocols. There is a code which peeks the data stream and decides which part of the code should handle the connection. In config.py you can find 'management_port' option which defines which port will be used. In config.py we have 'xmlrpc_enable' and 'jsonrpc_enable' which determine protocols available during runtime. With the latest vdsm both are enabled but keep in mind that xmlrpc is deprecated and will be removed soon. During host installation we attempt to connect to a host using jsonrpc first and if it fails we we attempt to use xmlrpc. Older vdsms provide only xmlrpc so this behavior is for backward compatibility. There are two binding modules bindingjsonrpc.py and bindingxmlrpc.py. Common module for both bindings is API.py There is a time when vdsm is not able to handle requests due to recovery logic which may take several seconds during this time we return code 99. Once the recovery is done vdsm returns correct codes like 0. Recovery occurs only during start of vdsm. Can you share the logs with above failure? ping verb was reused to detect whether vdsm is able to use jsonrpc. This verb originally is used to make sure that any network reconfiguration did not break connection to the engine. During the process of reconfiguration engine call ping and vdsm based on file update time can restore old network configuration in case of failure. There are 2 vdsm processes running with different user permissions.