API tools faq
paste
Advertisement
Guest User

virtual machine manager error

a guest
Apr 23rd, 2014
160
0
Never
Add comment
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
text 16.57 KB | None | 0 0
raw download clone embed print report
  1. [Mon, 24 Mar 2014 14:55:27 virt-manager 19336] DEBUG (connection:579) Connection managed save support: True
  2. [Mon, 24 Mar 2014 14:55:27 virt-manager 19336] DEBUG (connection:161) Using libvirt API for netdev enumeration
  3. [Mon, 24 Mar 2014 14:55:27 virt-manager 19336] DEBUG (connection:201) Using libvirt API for mediadev enumeration
  4. [Mon, 24 Mar 2014 14:55:29 virt-manager 19336] DEBUG (error:80) dialog message: Error launching details: Configuration server couldn't be contacted: D-BUS error: Unable to store a value at key '/apps/virt-manager/details/show-toolbar', as the configuration server has no writable databases. There are some common causes of this problem: 1) your configuration path file /etc/gconf/2/path doesn't contain any databases or wasn't found 2) somehow we mistakenly created two gconfd processes 3) your operating system is misconfigured so NFS file locking doesn't work in your home directory or 4) your NFS client machine crashed and didn't properly notify the server on reboot that file locks should be dropped. If you have two gconfd processes (or had two at the time the second was launched), logging out, killing all copies of gconfd, and logging back in may help. If you have stale locks, remove ~/.gconf*/*lock. Perhaps the problem is that you attempted to use GConf from two machines at once, and ORBit still has its default configuration that prevents remote CORBA connections - put "ORBIIOPIPv4=1" in /etc/orbitrc. As always, check the user.* syslog for details on problems gconfd encountered. There can only be one gconfd per home directory, and it must own a lockfile in ~/.gconfd and also lockfiles in individual storage locations such as ~/.gconf : Error launching details: Configuration server couldn't be contacted: D-BUS error: Unable to store a value at key '/apps/virt-manager/details/show-toolbar', as the configuration server has no writable databases. There are some common causes of this problem: 1) your configuration path file /etc/gconf/2/path doesn't contain any databases or wasn't found 2) somehow we mistakenly created two gconfd processes 3) your operating system is misconfigured so NFS file locking doesn't work in your home directory or 4) your NFS client machine crashed and didn't properly notify the server on reboot that file locks should be dropped. If you have two gconfd processes (or had two at the time the second was launched), logging out, killing all copies of gconfd, and logging back in may help. If you have stale locks, remove ~/.gconf*/*lock. Perhaps the problem is that you attempted to use GConf from two machines at once, and ORBit still has its default configuration that prevents remote CORBA connections - put "ORBIIOPIPv4=1" in /etc/orbitrc. As always, check the user.* syslog for details on problems gconfd encountered. There can only be one gconfd per home directory, and it must own a lockfile in ~/.gconfd and also lockfiles in individual storage locations such as ~/.gconf
  5.  
  6. Traceback (most recent call last):
  7. File "/usr/share/virt-manager/virtManager/engine.py", line 600, in _show_vm_helper
  8. details = self._get_details_dialog(uri, uuid)
  9. File "/usr/share/virt-manager/virtManager/engine.py", line 578, in _get_details_dialog
  10. obj = vmmDetails(con.get_vm(uuid))
  11. File "/usr/share/virt-manager/virtManager/details.py", line 533, in __init__
  12. self.refresh_vm_state()
  13. File "/usr/share/virt-manager/virtManager/details.py", line 1407, in refresh_vm_state
  14. self.toggle_toolbar(self.widget("details-menu-view-toolbar"))
  15. File "/usr/share/virt-manager/virtManager/details.py", line 1192, in toggle_toolbar
  16. self.config.set_details_show_toolbar(active)
  17. File "/usr/share/virt-manager/virtManager/config.py", line 504, in set_details_show_toolbar
  18. self.conf.set_bool(self.conf_dir + "/details/show-toolbar", state)
  19. GError: Configuration server couldn't be contacted: D-BUS error: Unable to store a value at key '/apps/virt-manager/details/show-toolbar', as the configuration server has no writable databases. There are some common causes of this problem: 1) your configuration path file /etc/gconf/2/path doesn't contain any databases or wasn't found 2) somehow we mistakenly created two gconfd processes 3) your operating system is misconfigured so NFS file locking doesn't work in your home directory or 4) your NFS client machine crashed and didn't properly notify the server on reboot that file locks should be dropped. If you have two gconfd processes (or had two at the time the second was launched), logging out, killing all copies of gconfd, and logging back in may help. If you have stale locks, remove ~/.gconf*/*lock. Perhaps the problem is that you attempted to use GConf from two machines at once, and ORBit still has its default configuration that prevents remote CORBA connections - put "ORBIIOPIPv4=1" in /etc/orbitrc. As always, check the user.* syslog for details on problems gconfd encountered. There can only be one gconfd per home directory, and it must own a lockfile in ~/.gconfd and also lockfiles in individual storage locations such as ~/.gconf
  20.  
  21. [Mon, 24 Mar 2014 14:55:31 virt-manager 19336] DEBUG (manager:186) Closing manager
  22. [Mon, 24 Mar 2014 14:55:31 virt-manager 19336] DEBUG (engine:333) window counter decremented to 0
  23. [Mon, 24 Mar 2014 14:55:31 virt-manager 19336] DEBUG (manager:186) Closing manager
  24. [Mon, 24 Mar 2014 14:55:31 virt-manager 19336] DEBUG (engine:406) Leaked <vmmConnection object at 0x2276140 (virtManager+connection+vmmConnection at 0x22f5140)>
  25. [Mon, 24 Mar 2014 14:55:31 virt-manager 19336] DEBUG (engine:406) Leaked <vmmDomain object at 0x26d62d0 (virtManager+domain+vmmDomain at 0x22f8980)>
  26. [Mon, 24 Mar 2014 14:55:31 virt-manager 19336] DEBUG (engine:406) Leaked <vmmDetails object at 0x26f37d0 (virtManager+details+vmmDetails at 0x23716a0)>
  27. [Mon, 24 Mar 2014 14:55:31 virt-manager 19336] DEBUG (engine:406) Leaked <vmmErrorDialog object at 0x26f4910 (virtManager+error+vmmErrorDialog at 0x236dae0)>
  28. [Mon, 24 Mar 2014 14:55:31 virt-manager 19336] DEBUG (engine:406) Leaked <vmmConsolePages object at 0x26f4960 (virtManager+console+vmmConsolePages at 0x2ac8080)>
  29. [Mon, 24 Mar 2014 14:55:31 virt-manager 19336] DEBUG (engine:406) Leaked <vmmErrorDialog object at 0x26f49b0 (virtManager+error+vmmErrorDialog at 0x22f8c20)>
  30. [Mon, 24 Mar 2014 14:55:31 virt-manager 19336] DEBUG (engine:408) Exiting app normally.
  31. [Mon, 24 Mar 2014 14:56:12 virt-manager 19418] INFO (cli:71) virt-manager startup
  32. [Mon, 24 Mar 2014 14:56:12 virt-manager 19418] DEBUG (virt-manager:306) Launched as: /usr/share/virt-manager/virt-manager.py
  33. [Mon, 24 Mar 2014 14:56:12 virt-manager 19418] DEBUG (virt-manager:307) GTK version: (2, 24, 22)
  34. [Mon, 24 Mar 2014 14:56:12 virt-manager 19418] DEBUG (virt-manager:308) virt-manager version: 0.9.5
  35. [Mon, 24 Mar 2014 14:56:12 virt-manager 19418] DEBUG (virt-manager:309) virtManager import: <module 'virtManager' from '/usr/share/virt-manager/virtManager/__init__.pyc'>
  36. [Mon, 24 Mar 2014 14:56:12 virt-manager 19418] DEBUG (cli:118) virtinst version: 0.600.4
  37. [Mon, 24 Mar 2014 14:56:12 virt-manager 19418] DEBUG (cli:119) virtinst import: <module 'virtinst' from '/usr/lib/python2.7/site-packages/virtinst/__init__.pyc'>
  38. [Mon, 24 Mar 2014 14:56:12 virt-manager 19419] DEBUG (engine:413) No inspection thread because libguestfs is too old, not available, or libvirt is not thread safe.
  39. [Mon, 24 Mar 2014 14:56:12 virt-manager 19419] DEBUG (systray:138) Showing systray: False
  40. [Mon, 24 Mar 2014 14:56:12 virt-manager 19419] DEBUG (engine:203) About to connect to uris []
  41. [Mon, 24 Mar 2014 14:56:12 virt-manager 19419] DEBUG (cli:83) Uncaught exception:
  42. Traceback (most recent call last):
  43. File "/usr/share/virt-manager/virtManager/manager.py", line 1202, in toggle_stats_visible
  44. set_stats[stats_id](visible)
  45. File "/usr/share/virt-manager/virtManager/config.py", line 340, in set_vmlist_disk_io_visible
  46. self.conf.set_bool(self.conf_dir + "/vmlist-fields/disk_usage", state)
  47. GError: Configuration server couldn't be contacted: D-BUS error: Unable to store a value at key '/apps/virt-manager/vmlist-fields/disk_usage', as the configuration server has no writable databases. There are some common causes of this problem: 1) your configuration path file /etc/gconf/2/path doesn't contain any databases or wasn't found 2) somehow we mistakenly created two gconfd processes 3) your operating system is misconfigured so NFS file locking doesn't work in your home directory or 4) your NFS client machine crashed and didn't properly notify the server on reboot that file locks should be dropped. If you have two gconfd processes (or had two at the time the second was launched), logging out, killing all copies of gconfd, and logging back in may help. If you have stale locks, remove ~/.gconf*/*lock. Perhaps the problem is that you attempted to use GConf from two machines at once, and ORBit still has its default configuration that prevents remote CORBA connections - put "ORBIIOPIPv4=1" in /etc/orbitrc. As always, check the user.* syslog for details on problems gconfd encountered. There can only be one gconfd per home directory, and it must own a lockfile in ~/.gconfd and also lockfiles in individual storage locations such as ~/.gconf
  48.  
  49. [Mon, 24 Mar 2014 14:56:12 virt-manager 19419] DEBUG (cli:83) Uncaught exception:
  50. Traceback (most recent call last):
  51. File "/usr/share/virt-manager/virtManager/manager.py", line 1202, in toggle_stats_visible
  52. set_stats[stats_id](visible)
  53. File "/usr/share/virt-manager/virtManager/config.py", line 343, in set_vmlist_network_traffic_visible
  54. state)
  55. GError: Configuration server couldn't be contacted: D-BUS error: Unable to store a value at key '/apps/virt-manager/vmlist-fields/network_traffic', as the configuration server has no writable databases. There are some common causes of this problem: 1) your configuration path file /etc/gconf/2/path doesn't contain any databases or wasn't found 2) somehow we mistakenly created two gconfd processes 3) your operating system is misconfigured so NFS file locking doesn't work in your home directory or 4) your NFS client machine crashed and didn't properly notify the server on reboot that file locks should be dropped. If you have two gconfd processes (or had two at the time the second was launched), logging out, killing all copies of gconfd, and logging back in may help. If you have stale locks, remove ~/.gconf*/*lock. Perhaps the problem is that you attempted to use GConf from two machines at once, and ORBit still has its default configuration that prevents remote CORBA connections - put "ORBIIOPIPv4=1" in /etc/orbitrc. As always, check the user.* syslog for details on problems gconfd encountered. There can only be one gconfd per home directory, and it must own a lockfile in ~/.gconfd and also lockfiles in individual storage locations such as ~/.gconf
  56.  
  57. [Mon, 24 Mar 2014 14:56:12 virt-manager 19419] DEBUG (manager:173) Showing manager
  58. [Mon, 24 Mar 2014 14:56:12 virt-manager 19419] DEBUG (engine:329) window counter incremented to 1
  59. [Mon, 24 Mar 2014 14:56:12 virt-manager 19419] DEBUG (cli:83) Uncaught exception:
  60. Traceback (most recent call last):
  61. File "/usr/share/virt-manager/virtManager/manager.py", line 490, in window_resized
  62. self.config.set_manager_window_size(event.width, event.height)
  63. File "/usr/share/virt-manager/virtManager/config.py", line 655, in set_manager_window_size
  64. self.conf.set_int(self.conf_dir + "/manager_window_width", w)
  65. GError: Configuration server couldn't be contacted: D-BUS error: Unable to store a value at key '/apps/virt-manager/manager_window_width', as the configuration server has no writable databases. There are some common causes of this problem: 1) your configuration path file /etc/gconf/2/path doesn't contain any databases or wasn't found 2) somehow we mistakenly created two gconfd processes 3) your operating system is misconfigured so NFS file locking doesn't work in your home directory or 4) your NFS client machine crashed and didn't properly notify the server on reboot that file locks should be dropped. If you have two gconfd processes (or had two at the time the second was launched), logging out, killing all copies of gconfd, and logging back in may help. If you have stale locks, remove ~/.gconf*/*lock. Perhaps the problem is that you attempted to use GConf from two machines at once, and ORBit still has its default configuration that prevents remote CORBA connections - put "ORBIIOPIPv4=1" in /etc/orbitrc. As always, check the user.* syslog for details on problems gconfd encountered. There can only be one gconfd per home directory, and it must own a lockfile in ~/.gconfd and also lockfiles in individual storage locations such as ~/.gconf
  66.  
  67. [Mon, 24 Mar 2014 14:56:12 virt-manager 19419] DEBUG (cli:83) Uncaught exception:
  68. Traceback (most recent call last):
  69. File "/usr/share/virt-manager/virtManager/manager.py", line 490, in window_resized
  70. self.config.set_manager_window_size(event.width, event.height)
  71. File "/usr/share/virt-manager/virtManager/config.py", line 655, in set_manager_window_size
  72. self.conf.set_int(self.conf_dir + "/manager_window_width", w)
  73. GError: Configuration server couldn't be contacted: D-BUS error: Unable to store a value at key '/apps/virt-manager/manager_window_width', as the configuration server has no writable databases. There are some common causes of this problem: 1) your configuration path file /etc/gconf/2/path doesn't contain any databases or wasn't found 2) somehow we mistakenly created two gconfd processes 3) your operating system is misconfigured so NFS file locking doesn't work in your home directory or 4) your NFS client machine crashed and didn't properly notify the server on reboot that file locks should be dropped. If you have two gconfd processes (or had two at the time the second was launched), logging out, killing all copies of gconfd, and logging back in may help. If you have stale locks, remove ~/.gconf*/*lock. Perhaps the problem is that you attempted to use GConf from two machines at once, and ORBit still has its default configuration that prevents remote CORBA connections - put "ORBIIOPIPv4=1" in /etc/orbitrc. As always, check the user.* syslog for details on problems gconfd encountered. There can only be one gconfd per home directory, and it must own a lockfile in ~/.gconfd and also lockfiles in individual storage locations such as ~/.gconf
  74.  
  75. [Mon, 24 Mar 2014 14:56:12 virt-manager 19419] DEBUG (engine:156) Determining default libvirt URI
  76. [Mon, 24 Mar 2014 14:56:12 virt-manager 19419] DEBUG (packageutils:41) No PackageKit packages to search for.
  77. [Mon, 24 Mar 2014 14:56:12 virt-manager 19419] ERROR (engine:228) Error connecting to qemu:///system
  78. Traceback (most recent call last):
  79. File "/usr/share/virt-manager/virtManager/engine.py", line 218, in connect_to_uri
  80. conn = self.add_conn(uri)
  81. File "/usr/share/virt-manager/virtManager/engine.py", line 441, in add_conn
  82. self.config.add_conn(conn.get_uri())
  83. File "/usr/share/virt-manager/virtManager/config.py", line 623, in add_conn
  84. gconf.VALUE_STRING, uris)
  85. GError: Configuration server couldn't be contacted: D-BUS error: Unable to store a value at key '/apps/virt-manager/connections/uris', as the configuration server has no writable databases. There are some common causes of this problem: 1) your configuration path file /etc/gconf/2/path doesn't contain any databases or wasn't found 2) somehow we mistakenly created two gconfd processes 3) your operating system is misconfigured so NFS file locking doesn't work in your home directory or 4) your NFS client machine crashed and didn't properly notify the server on reboot that file locks should be dropped. If you have two gconfd processes (or had two at the time the second was launched), logging out, killing all copies of gconfd, and logging back in may help. If you have stale locks, remove ~/.gconf*/*lock. Perhaps the problem is that you attempted to use GConf from two machines at once, and ORBit still has its default configuration that prevents remote CORBA connections - put "ORBIIOPIPv4=1" in /etc/orbitrc. As always, check the user.* syslog for details on problems gconfd encountered. There can only be one gconfd per home directory, and it must own a lockfile in ~/.gconfd and also lockfiles in individual storage locations such as ~/.gconf
  86. [Mon, 24 Mar 2014 14:56:13 virt-manager 19419] DEBUG (connection:963) Scheduling background open thread for qemu:///system
  87. [Mon, 24 Mar 2014 14:56:13 virt-manager 19419] DEBUG (connection:1019) Background 'open connection' thread is running
  88. [Mon, 24 Mar 2014 14:56:17 virt-manager 19419] DEBUG (connection:1070) Background open thread complete, scheduling notify
  89. [Mon, 24 Mar 2014 14:56:17 virt-manager 19419] DEBUG (connection:1075) Notifying open result
  90. [Mon, 24 Mar 2014 14:56:17 virt-manager 19419] DEBUG (connection:1082) qemu:///system capabilities:
Advertisement
Add Comment
Please, Sign In to add comment
Advertisement
Public Pastes
Advertisement
We use cookies for various purposes including analytics. By continuing to use Pastebin, you agree to our use of cookies as described in the Cookies Policy.  OK, I Understand
Not a member of Pastebin yet?
Sign Up, it unlocks many cool features!