VM Manager не подключается к XEN на openSUSE 11.4

Выполнил новую установку openSUSE 11.4, провел стандартное обновление, установил через YaST2 > “Install Hypervisor and Tools” - XEN (поставились все необходимые пакеты включая libvirt), добавился Ethernet bridge - br0), включил автозапуск для libvirt, настроил GRUB на автозапуск XEN, перезагрузился.
Запускаю “Virtual Machine Manager”, при попытке подключения к локальному хосту получаю ошибку:

**Unable to open a connection to the Xen hypervisor/daemon.
Verify that:
 - A Xen host kernel was booted
 - The Xen service has been started**
*Details*
*unable to connect to 'localhost:8000': Connection refused

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/connection.py", line 983, in _try_open
    None], flags)
  File "/usr/lib64/python2.7/site-packages/libvirt.py", line 107, in openAuth
    if ret is None:raise libvirtError('virConnectOpenAuth() failed')
libvirtError: unable to connect to 'localhost:8000': Connection refused
*

>:)Куда смотреть, в чем проблема?

Не нашел как подправить/дополнить свое сообщение:
Во время настройки виртуализации через YaST2 > “Install Hypervisor and Tools” (независимо XEN или KVM), столкнулся с проблемой автоматической настройки Ethernet Bridge - при установке системы сетевые адаптеры автоматически настраиваются на режим активации Device Activation - On NFSroot (т.е. блокируется возможность отключения интерфейса), поэтому авто-настройка бриджа стандартным мастером YaST не может провести нужную процедуру. (это описано тут](http://forums.opensuse.org/english/get-technical-help-here/network-internet/455511-x64-xen-bridge-configured-but-no-br0-no-internet-connection.html)). Для нормальной настройки работы сети, необходимо перед запуском мастера установки Виртуализации, переключить режимы запуска сетевых интерфейсов в “At Boot Time” или “On Cable Connection”, а также желательно после этого выполнить перезагрузку (проверил, нормально обрабатывается и без перезагрузки).

Есть промежуточное решение проблемы:
Повторил все процедуры, за исключением обновления - все работает нормально. Скорее всего проблема вызвана каким-то патчем/обновлением.

После установки обновлений, и перезагрузки системы получил ту же проблему.

Кто может сказать куда копать???>:)

Ответов нет >:(
Продолжаю ковырять тему сам. Тут](http://www.sql.ru/forum/actualthread.aspx?tid=644398) нашел подобную проблему, воспользовался советами:

  1. Проверил состояние:
**# uname -r**
2.6.37.6-0.5-xen
**# chkconfig | grep xen**
xencommons           on
xend                 on
xendomains           on

Ядро правильное, службы активны.
2. Пробую консольный Xen-менеджер:

**# xm uptime**
Error: Unable to connect to xend: Connection refused. Is xend running?

Вот тут-то уже проблема :sarcastic: спросил Гугла - есть новая тема](http://www.novell.com/support/viewContent.do?externalId=7002198&sliceId=1) для раздумий.
3. Продолжаем:

**# rcxend status**
Checking status of xend (pid 3719 3717)                              running

или так

**# service xend status**
Checking status of xend (pid 3719 3717)                              running

и

**# rclibvirtd status**
Checking status of libvirtd                                          running
  1. Изучаем логи:
** # cat /var/log/xen/xend-debug.log**
Xend started at Sat Jun 18 13:59:05 2011.
Exception in thread UnixHttpServer:
Traceback (most recent call last):
  File "/usr/lib64/python2.7/threading.py", line 530, in __bootstrap_inner
    self.run()
  File "/usr/lib64/python2.7/threading.py", line 483, in run
    self.__target(*self.__args, **self.__kwargs)
  File "/usr/lib64/python2.7/site-packages/xen/web/httpserver.py", line 312, in run
    (sock, addr) = self.accept()
  File "/usr/lib64/python2.7/site-packages/xen/web/httpserver.py", line 331, in accept
    return self.socket.accept()
  File "/usr/lib64/python2.7/socket.py", line 200, in accept
    sock, addr = self._sock.accept()
error: [Errno 22] Invalid argument

Traceback (most recent call last):
  File "/usr/lib64/python2.7/site-packages/xen/xend/server/Hald.py", line 55, in shutdown
    os.kill(self.pid, signal.SIGINT)
OSError: [Errno 3] No such process
Xend started at Sat Jun 18 14:57:22 2011.
Exception starting xend: (111, 'Connection refused')
Xend started at Sat Jun 18 15:31:05 2011.
Exception starting xend: (111, 'Connection refused')
Xend started at Sat Jun 18 19:54:59 2011.
Exception starting xend: (111, 'Connection refused')

Тут хорошо видно - до установки обновлений был успешный запуск в 13:59:05, после перезагрузки с обновлениями в 14:57:22 появилась проблема - (111, ‘Connection refused’).
5. Пытаюсь воспользоваться советами от Novell…

Никто не ответил>:(, отвечаю сам:(
Проблема вовсе не в обновлениях, а в состоянии системных служб:

  1. libvirtd - daemon for libvirt virtualization API - This is a daemon for managing QEMU guest instances and libvirt virtual networks See libvirt: The virtualization API
  2. libvirt-guest - suspend/resume libvirt guest on shutdown/boot - This is a script for suspending active libvirt guests on shutdown and resuming them on next boot See libvirt: The virtualization API
  3. xencommons - Start/stop xenstored and xenconsoled - Starts and stops the daemons neeeded for xl/libxenlight
  4. xend - Starts and stops the Xen management daemon - Starts and stops the Xen management daemon. xend is needed to create and manage VMs on Xen.
  5. xendomains - Starts and stops Xen VMs - Starts and stops Xen VMs automatically when the host starts and stops.

Если запущенна только xend, обеспечивается нормальное выполнение xm (Xen management user interface), VMM (Virtual Machine Manager) - так же работает но в нем недоступно управление сетью и хранилищами. Для этого необходимо запустить libvirtd. Однако это не закрывает все вопросы, в частности - не происходит автоматический запуск гостевых-VM при загрузке хоста, несмотря на то, что опция запуска отмечена.

В предыдущем релизе openSUSE 11.3 это решалось запуском xendomains, при этом служб libvirt-guest и xencommons там не было. Если openSUSE 11.4 активировать службу xendomains - возникает описанная в первом посте проблема.

Вполне возможно, что потратив время на эксперименты с разными комбинацией состояний данных служб можно добиться нормально работы всех функций системы виртуализации.

Судя по описанию новые службы выполняют эквивалентные функции, в частности старый xendomains может быть заменен libvirt-guest (это мое личное предположение). Судя по статьям с описанием подобных проблем, основной причиной такой ситуации является отказ от развития технологии Xen в пользу KVM и соответствующее развитие libvirt которое и привело к появлению libvirt-guest.

как вариант, посмотрите содержимое xendomains и в чём именно заключается конфликт.