Проблема: SLES 11+Xen+Solaris (SLES 11+Xen+Solaris - проблема с установкой соляры)

[ACDC]

В наличии - обычный комп RAM 4GB , CPU 2160 1,8 GHz, 1 HDD 1TB. Установлен SLES-11-x86_64.
Задача - установить Solaris x86 на VM.
В качестве основы для VM выбран Xen, который установлен в режиме Paravirtual.

Испробованы 2 варианта решения:
1. Согласно _http://en.opensuse.org/How_to_Install_a_Xen_VM_Server и далее по пунктам.
На этапе _http://en.opensuse.org/How_to_Install_a_VM's_OS_from_Installation_Source
iso-шник Solaris 10 x86 не открывается! Аналогичные действия для установки на VM SLES 11 - без проблем,
все запускается и работает. Видимо проблема в загрузчике Solaris? Поэтому испробован вариант 2.

2. Действуем согласно _http://www.sakana.fr/blog/2008/12/14/xen-opensolaris-200811-domu-running-on-a-linux-dom0/

Подготовлен конфиг osol_install_cdrom.py:
name = "osol-install"
vcpus = 1
memory = "1024"
bootloader = "/usr/bin/pygrub"
kernel = "/opt/xen/vm/kernels/opensolaris2009_06/unix"
ramdisk = "/boot/x86.microroot"
#ramdisk = "/opt/xen/vm/kernels/opensolaris2009_06/x86.microroot"
extra = "/opt/xen/vm/kernels/opensolaris2009_06/unix -B console=ttya,livemode=text"
disk = ['file:/opt/distr/OSOL2009_06/osol-0906-x86.iso,6:cdrom,r','file:/opt/xen/vm/images/opensolaris2009_06,root.img,0,w']
vif = ['']
on_shutdown = "destroy"
on_reboot = "destroy"
on_crash = "preserve"

тут: sol-0906-x86.iso - iso образ OpenSolaris2009
/boot/x86.microroot"
unix" пробовались из /platform/i86pc/kernel и platform/i86xpv/kernel
и x86.microroot из /boot/x86.microroot

Попытки запустить Solaris 10, а затем и OpenSolaris2009_06 на шаге Step 4.2 : Start the OpenSolaris DomU for installing
приводят к сообщению:

# xm create -с sol10_install_cdrom.py
Using config file "./sol10_install_cdrom.py".
Error: Boot loader didn't return any data!

/var/log/xen/xend.log:
[2010-02-02 16:00:29 3975] DEBUG (XendDomainInfo:2446) XendDomainInfo.destroy: domid=21
[2010-02-02 16:00:29 3975] DEBUG (XendDomainInfo:1976) No device model
[2010-02-02 16:00:29 3975] DEBUG (XendDomainInfo:1978) Releasing devices
[2010-02-02 16:00:29 3975] ERROR (XendDomainInfo:96) Domain construction failed
Traceback (most recent call last):
File "/usr/lib64/python2.6/site-packages/xen/xend/XendDomainInfo.py", line 94, in create
vm.start()
File "/usr/lib64/python2.6/site-packages/xen/xend/XendDomainInfo.py", line 450, in start
XendTask.log_progress(31, 60, self._initDomain)
File "/usr/lib64/python2.6/site-packages/xen/xend/XendTask.py", line 209, in log_progress
retval = func(*args, **kwds)
File "/usr/lib64/python2.6/site-packages/xen/xend/XendDomainInfo.py", line 2234, in _initDomain
self._configureBootloader()
File "/usr/lib64/python2.6/site-packages/xen/xend/XendDomainInfo.py", line 2643, in _configureBootloader
bootloader_args, kernel, ramdisk, args)
File "/usr/lib64/python2.6/site-packages/xen/xend/XendBootloader.py", line 189, in bootloader
raise VmError, msg
VmError: Boot loader didn't return any data!

Очень нужна консультация по данной проблеме , в гугле ничего путного нет, может все таки кто-то запускал Solaris под Xen и знает, что ей не хватает?

[step_slim]

Всё же я думаю проблема не в Солярке, а именно в XEN и его не совсем нормальной поддержки паравиртуализованного режима, для определённых ОСей, я вот как не бился, но запустит Фряху в этом режиме на XEN не смог и докопиливал модули и всё такое, увы. Так же и Винда мне шиш показала А вот Убунта и Мандрива запустились. Но из-за очень мудрённого XEN и его требований к железу, предпочёл использовать VB. Так же, можете проверить, а поддерживает Ваш процессор паравиртуальный режим?- возможно проблема намного проще

з.ы Тут про проверку железа инфа: http://www.xgu.ru/wiki/Windows_XP_%D0%B2_Xen

[Loky]

Всё же я думаю проблема не в Солярке, а именно в XEN и его не совсем нормальной поддержки паравиртуализованного режима, для определённых ОСей, я вот как не бился, но запустит Фряху в этом режиме на XEN не смог и докопиливал модули и всё такое, увы. Так же и Винда мне шиш показала А вот Убунта и Мандрива запустились. Но из-за очень мудрённого XEN и его требований к железу, предпочёл использовать VB. Так же, можете проверить, а поддерживает Ваш процессор паравиртуальный режим?- возможно проблема намного проще

з.ы Тут про проверку железа инфа: http://www.xgu.ru/wiki/Windows_XP_%D0%B2_Xen

Режим паравиртуализации должен поддерживаться гостевой ОС, в данном случае - солярой. XEN в данном случае не при чём. Заявления про "его не совсем нормальной поддержки" без пруфлинка - считается пустым трёпом.

Топикстартеру - уточните что соляра поддерживает режим паравиртуализации. Возможные варианты решения:
1. ставить в режиме полной виртуализации
2. сменить XEN на что-нить более интересное - VMware, VirtualBox, etc

[ACDC]

Всё же я думаю проблема не в Солярке, а именно в XEN и его не совсем нормальной поддержки паравиртуализованного режима, для определённых ОСей, я вот как не бился, но запустит Фряху в этом режиме на XEN не смог и докопиливал модули и всё такое, увы. Так же и Винда мне шиш показала А вот Убунта и Мандрива запустились. Но из-за очень мудрённого XEN и его требований к железу, предпочёл использовать VB. Так же, можете проверить, а поддерживает Ваш процессор паравиртуальный режим?- возможно проблема намного проще

з.ы Тут про проверку железа инфа: http://www.xgu.ru/wiki/Windows_XP_%D0%B2_Xen

Режим паравиртуализации должен поддерживаться гостевой ОС, в данном случае - солярой. XEN в данном случае не при чём. Заявления про "его не совсем нормальной поддержки" без пруфлинка - считается пустым трёпом.

Топикстартеру - уточните что соляра поддерживает режим паравиртуализации. Возможные варианты решения:
1. ставить в режиме полной виртуализации
2. сменить XEN на что-нить более интересное - VMware, VirtualBox, etc

просмотр _http://ru.wikipedia.org/wiki/Сравнение_виртуальных_машин склонил выбор в сторону virtualbox,

отсюда _http://www.virtualbox.org/wiki/Linux_Downloads
взят SUSE Linux Enterprise Server 11 (SLES11) который для AMD64

приу установке VirtualBox-3.1-3.1.2_56127_sles11.0-1.x86_64.rpm пишет:
# rpm -ivh VirtualBox-3.1-3.1.2_56127_sles11.0-1.x86_64.rpm
error: Failed dependencies:
pam-devel is needed by VirtualBox-3.1-3.1.2_56127_sles11.0-1.x86_64

но в sles 11 pam-devel уже нет почему-то. Проверил - в sles 10 pam-devel есть!
и виде рпм-а не могу найти его , странно...

[k0da]

ACDC
pam-devel на SDK диске

[step_slim]

приу установке VirtualBox-3.1-3.1.2_56127_sles11.0-1.x86_64.rpm пишет:
# rpm -ivh VirtualBox-3.1-3.1.2_56127_sles11.0-1.x86_64.rpm
error: Failed dependencies:
pam-devel is needed by VirtualBox-3.1-3.1.2_56127_sles11.0-1.x86_64

но в sles 11 pam-devel уже нет почему-то. Проверил - в sles 10 pam-devel есть!
и виде рпм-а не могу найти его , странно...

Посмотрите тут: http://software.opensuse.org/search?q=VirtualBox

Режим паравиртуализации должен поддерживаться гостевой ОС, в данном случае - солярой. XEN в данном случае не при чём. Заявления про "его не совсем нормальной поддержки" без пруфлинка - считается пустым трёпом.

Режим паравертуализации должен поддерживаться ПРОЦЕССОРОМ, а не ОСью. Если Ваш процессор способен разделить свои ресурсы для обеспечения нормального запуска 2х ОС, то пофигу, что Вы будите ставить, хоть уж-ОС, но если Ваше железо не даёт такой поддержки, то в XEN не какими силами Вы не запустите виртуальную машину.

[aSteklov]

Режим паравертуализации должен поддерживаться ПРОЦЕССОРОМ, а не ОСью. Если Ваш процессор способен разделить свои ресурсы для обеспечения нормального запуска 2х ОС, то пофигу, что Вы будите ставить, хоть уж-ОС, но если Ваше железо не даёт такой поддержки, то в XEN не какими силами Вы не запустите виртуальную машину.

Вам двойка.
Суть Паравиртуализации - это подготовака ядра ОС. Ядро модифицируется для исполнения в виртуальной среде.
Это отличие от полной виртуализации - эмуляции аппаратуры программным обеспечением виртуальной среды и
аппаратной виртуализации - добавления в процессор инструкций, облегчающих выполнение на аппаратном уровне эмуляции

[aSteklov]

Error: Boot loader didn't return any data!

А у вас ядро не найдено загрузчиком. О причинах давайте подумаем сообща. Но суть - до загрузки ядра соляриса не дошло по причине того, что оно не найдено загрузчиком

[step_slim]

Режим паравертуализации должен поддерживаться ПРОЦЕССОРОМ, а не ОСью. Если Ваш процессор способен разделить свои ресурсы для обеспечения нормального запуска 2х ОС, то пофигу, что Вы будите ставить, хоть уж-ОС, но если Ваше железо не даёт такой поддержки, то в XEN не какими силами Вы не запустите виртуальную машину.

Вам двойка.
Суть Паравиртуализации - это подготовака ядра ОС. Ядро модифицируется для исполнения в виртуальной среде.
Это отличие от полной виртуализации - эмуляции аппаратуры программным обеспечением виртуальной среды и
аппаратной виртуализации - добавления в процессор инструкций, облегчающих выполнение на аппаратном уровне эмуляции

Аналогичную оценку я ставлю Вам
В данном топике, мы рассматриваем такие системы Виртуализации как XEN и VB, а именно эти системы очень требовательны к ПРОЦЕССОРУ, то что Вы привели, это контекст VMware, там именно так происходит виртуализация системы, в данная программа абсолютно не учитывает возможности Вашего железа, в частности поддержки процессора. Так же, в последних версиях VB, появилась возможность оттяпывать даже видео карту и разделять её на виртуальные машины, если опять же верить разработчикам этой программы, что в новой версии VB есть возможность установки родного драйвера видео карты и полной поддержки 3D.
По поводу XEN, есть хорошая инструкция, которую написали ещё в 2003 году, но она актуальна по сей день: http://www.cl.cam.ac.uk/research/srg/netos...003-xensosp.pdf

Компания Novell поставляет платформу SUSE Linux Enterprise 10, интегрированную с гипервизором Xen 3.0. Со своей стороны компания дополняет XEN средством для управления YaST, оно имеет графический интерфейс и может распознавать, обладает ли сервер, на котором оно установлено поддержкой для аппаратной виртуализации и в зависимости от конфигурации сервера выбирает автоматически режим паравиртуализации или виртуализации, использующей аппаратные возможности.

А это вот что Novell сама говорит о XEN, если вы обратите внимание, то там во основном идёт ссылка на АППАРАТНУЮ поддержку, но не программную.

[aSteklov]

bootloader = "/usr/bin/pygrub"
kernel = "/opt/xen/vm/kernels/opensolaris2009_06/unix"
ramdisk = "/boot/x86.microroot"

Кажется, понял. Я предполагаю, что Вы скопировали ядро из iso-образа в файловую систему Dom0 сюда - /opt/xen/vm/kernels/opensolaris2009_06/unix, но при этом используете pygrub, так?

то что Вы привели, это контекст VMware

То, что я привел - это Определения. Раз не верите мне, обратитесь например к wiki: Паравиртуализация и Аппаратная виртуализация - прочтение этих двух ресурсов возможно поможет вам понять, что вы таки путаете Аппаратную виртуализацию и Паравиртуализацию.

[aSteklov]

Код: Выделить всё

dv2-1110er:/mnt # mount data/xen/openSolaris/osol-0906-x86.iso ./iso -o loop
dv2-1110er:/mnt # cp iso/platform/i86xpv/kernel/unix ./data/xen/openSolaris/
dv2-1110er:/mnt # cp iso/boot/x86.microroot ./data/xen/openSolaris/
dv2-1110er:/mnt/data/xen/openSolaris # touch xen.conf
dv2-1110er:/mnt/data/xen/openSolaris # mcedit xen.conf

dv2-1110er:/mnt/data/xen/openSolaris # xm create -c ./xen.conf
Using config file "././xen.conf".
Started domain test11 (id=5)
                            v3.4.1_19718_04-2.1 chgset '19718'
SunOS Release 5.11 Version snv_111b 32-bit
Copyright 1983-2009 Sun Microsystems, Inc.  All rights reserved.
Use is subject to license terms.
Hostname: opensolaris
Remounting root read/write
Probing for device nodes ...
Preparing live image for use
Done mounting Live image
USB keyboard
 1. Albanian                      23. Lithuanian

Где xen.conf:

Код: Выделить всё

name = 'test11'
memory = '256'
disk = [ 'file:/mnt/data/xen/openSolaris/osol-0906-x86.iso,1:cdrom,r' ]
vif = [ '' ]
on_shutdown = 'destroy'
on_reboot = 'destroy'
on_crash = 'destroy'
kernel = '/mnt/data/xen/openSolaris/unix'
ramdisk = '/mnt/data/xen/openSolaris/x86.microroot'
extra = '/platform/i86xpv/kernel/unix - nowin -B install_media=cdrom'

Уважаемый ACDC, надеюсь на частое посещение вами форума - через полгода планирую начать изучать openSolaris, будет куча вопросов у меня.
Конфиг не пригоден для установки - нет собственно виртуального диска, куда ставить, нет поддержки сети

[ACDC]

bootloader = "/usr/bin/pygrub"
kernel = "/opt/xen/vm/kernels/opensolaris2009_06/unix"
ramdisk = "/boot/x86.microroot"

Кажется, понял. Я предполагаю, что Вы скопировали ядро из iso-образа в файловую систему Dom0 сюда - /opt/xen/vm/kernels/opensolaris2009_06/unix, но при этом используете pygrub, так?

то что Вы привели, это контекст VMware

То, что я привел - это Определения. Раз не верите мне, обратитесь например к wiki: Паравиртуализация и Аппаратная виртуализация - прочтение этих двух ресурсов возможно поможет вам понять, что вы таки путаете Аппаратную виртуализацию и Паравиртуализацию.

Ага!
Именно так, /platform/i86xpv/kernelunix & /boot/x86.microroot скопированы с osol-0906-x86.iso,
использую bootloader = "/usr/bin/pygrub"

[ACDC]

Код: Выделить всё

dv2-1110er:/mnt # mount data/xen/openSolaris/osol-0906-x86.iso ./iso -o loop
dv2-1110er:/mnt # cp iso/platform/i86xpv/kernel/unix ./data/xen/openSolaris/
dv2-1110er:/mnt # cp iso/boot/x86.microroot ./data/xen/openSolaris/
dv2-1110er:/mnt/data/xen/openSolaris # touch xen.conf
dv2-1110er:/mnt/data/xen/openSolaris # mcedit xen.conf

dv2-1110er:/mnt/data/xen/openSolaris # xm create -c ./xen.conf
Using config file "././xen.conf".
Started domain test11 (id=5)
                            v3.4.1_19718_04-2.1 chgset '19718'
SunOS Release 5.11 Version snv_111b 32-bit
Copyright 1983-2009 Sun Microsystems, Inc.  All rights reserved.
Use is subject to license terms.
Hostname: opensolaris
Remounting root read/write
Probing for device nodes ...
Preparing live image for use
Done mounting Live image
USB keyboard
 1. Albanian                      23. Lithuanian

Где xen.conf:

Код: Выделить всё

name = 'test11'
memory = '256'
disk = [ 'file:/mnt/data/xen/openSolaris/osol-0906-x86.iso,1:cdrom,r' ]
vif = [ '' ]
on_shutdown = 'destroy'
on_reboot = 'destroy'
on_crash = 'destroy'
kernel = '/mnt/data/xen/openSolaris/unix'
ramdisk = '/mnt/data/xen/openSolaris/x86.microroot'
extra = '/platform/i86xpv/kernel/unix - nowin -B install_media=cdrom'

Уважаемый ACDC, надеюсь на частое посещение вами форума - через полгода планирую начать изучать openSolaris, будет куча вопросов у меня.
Конфиг не пригоден для установки - нет собственно виртуального диска, куда ставить, нет поддержки сети

Начинал когда-то с соляриса 2.5, теперь вот возникла необходимость поднять кое какие задачки на солярке...

аналогично подготовил конфиг:
name = 'opensolaris2009'
memory = '512'
disk = [ 'file:/opt/distr/OSOL2009_06/osol-0906-x86.iso,1:cdrom,r',
'file:/opt/xen/vm/images/opensolaris2009_06boot.img,0,w']
#vif = [ '' ]
vif = [ 'ip=x.x.x.x,mac=00:19:db:dc:49:5d,bridge=eth0' ]
on_shutdown = 'destroy'
on_reboot = 'destroy'
on_crash = 'destroy'
kernel = '/opt/xen/vm/kernels/opensolaris2009_06/unix'
ramdisk = '/opt/xen/vm/kernels/opensolaris2009_06/x86.microroot'
extra = '/opt/xen/vm/kernels/opensolaris2009_06 - nowin -B install_media=cdrom'

#xm create -c opensol.conf
#Using config file "./opensol.conf".

тут пауза минуты полторы...

хm list кажет
Name ID Mem VCPUs State Time(s)
Domain-0 0 2720 2 r----- 9676.1
opensolaris2009 29 512 1 --p--- 0.0

затем все таки
# Error: Device 0 (vif) could not be connected. Hotplug scripts not working.

[aSteklov]

vif = [ 'ip=x.x.x.x,mac=00:19:db:dc:49:5d,bridge=eth0' ]
....
# Error: Device 0 (vif) could not be connected. Hotplug scripts not working.

Вы знаете, а я с сеткой и не пробовал. Давайте вы для начала уберете запись о сети, попробуете с моим конфигом, запустится - будем с сетью разбираться. Тут же четко видно - проблема с сетевым интерфейсом.

Предлагаю:
1. Попробовать без сети вообще.
2. Если пойдет без сети:
- убедиться, что есть настроенный бридж (br0)
- запись про сеть сделать такую: vif=[ 'bridge=br0' ]
Если у вас там несколько машин и вы от бриджа отошли, то ... то надо подумать, почему ему eth0 не нравится :-)
Я полагаю, что из-за того, что он включен в бридж

[aSteklov]

Вот, вроде вышло, в прилагаемом файле пример

[aSteklov]

Код: Выделить всё

jack@opensolaris:~$ ifconfig xnf0
xnf0: flags=1004843<UP,BROADCAST,RUNNING,MULTICAST,DHCP,IPv4> mtu 1500 index 2
        inet 192.168.0.72 netmask ffffff00 broadcast 192.168.0.255
jack@opensolaris:~$ ping 192.168.0.1
192.168.0.1 is alive
jack@opensolaris:~$

И я как-то жестко подошел со строкой memory = '256'. Лучше увеличить - отклик системы был долгим до увеличения.

[ACDC]

Вот, вроде вышло, в прилагаемом файле пример

Можно посмотреть результаты ifconfig ?
Плюс из конфига xend-config.sxp строчки для (network-script ) , (vif-script vif-bridge)?

[aSteklov]

Можно посмотреть результаты ifconfig ?
Плюс из конфига xend-config.sxp строчки для (network-script ) , (vif-script vif-bridge)?

Код: Выделить всё

dv2-1110er:/etc/xen # ifconfig -a
br0       Link encap:Ethernet  HWaddr 00:21:CC:3A:F2:55
          inet addr:192.168.0.52  Bcast:192.168.0.255  Mask:255.255.255.0
          inet6 addr: fe80::221:ccff:fe3a:f255/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:206803 errors:0 dropped:0 overruns:0 frame:0
          TX packets:266034 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:24908195 (23.7 Mb)  TX bytes:202886635 (193.4 Mb)

eth0      Link encap:Ethernet  HWaddr 00:21:CC:3A:F2:55
          inet6 addr: fe80::221:ccff:fe3a:f255/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:206803 errors:0 dropped:0 overruns:0 frame:0
          TX packets:266041 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:27803449 (26.5 Mb)  TX bytes:202887213 (193.4 Mb)
          Interrupt:164 Base address:0x4000

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:301341 errors:0 dropped:0 overruns:0 frame:0
          TX packets:301341 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:208717636 (199.0 Mb)  TX bytes:208717636 (199.0 Mb)

pan0      Link encap:Ethernet  HWaddr 66:85:65:47:7B:51
          BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

wimax0    Link encap:Ethernet  HWaddr 00:24:91:3B:3B:3E
          inet addr:10.128.59.31  Bcast:10.128.63.255  Mask:255.255.248.0
          inet6 addr: fe80::224:91ff:fe3b:3b3e/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1386  Metric:1
          RX packets:4318 errors:0 dropped:0 overruns:0 frame:0
          TX packets:4880 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:500
          RX bytes:2884365 (2.7 Mb)  TX bytes:1022441 (998.4 Kb)

Код: Выделить всё

cat xend-config.sxp
# -*- sh -*-

#
# Xend configuration file.
#

# This example configuration is appropriate for an installation that
# utilizes a bridged network configuration. Access to xend via http
# is disabled.

# Commented out entries show the default for that entry, unless otherwise
# specified.

#(logfile /var/log/xen/xend.log)
#(loglevel DEBUG)

# Uncomment the line below.  Set the value to flask, acm, or dummy to
# select a security module.

#(xsm_module_name dummy)

# The Xen-API server configuration.
#
# This value configures the ports, interfaces, and access controls for the
# Xen-API server.  Each entry in the list starts with either unix, a port
# number, or an address:port pair.  If this is "unix", then a UDP socket is
# opened, and this entry applies to that.  If it is a port, then Xend will
# listen on all interfaces on that TCP port, and if it is an address:port
# pair, then Xend will listen on the specified port, using the interface with
# the specified address.
#
# The subsequent string configures the user-based access control for the
# listener in question.  This can be one of "none" or "pam", indicating either
# that users should be allowed access unconditionally, or that the local
# Pluggable Authentication Modules configuration should be used.  If this
# string is missing or empty, then "pam" is used.
#
# The final string gives the host-based access control for that listener. If
# this is missing or empty, then all connections are accepted.  Otherwise,
# this should be a space-separated sequence of regular expressions; any host
# with a fully-qualified domain name or an IP address that matches one of
# these regular expressions will be accepted.
#
# Example: listen on TCP port 9363 on all interfaces, accepting connections
# only from machines in example.com or localhost, and allow access through
# the unix domain socket unconditionally:
#
#   (xen-api-server ((9363 pam '^localhost$ example\\.com$')
#                    (unix none)))
#
# Optionally, the TCP Xen-API server can use SSL by specifying the private
# key and certificate location:
#
#                    (9367 pam '' /etc/xen/xen-api.key /etc/xen/xen-api.crt)
#
# Default:
#   (xen-api-server ((unix)))


#(xend-http-server no)
(xend-unix-server yes)
#(xend-tcp-xmlrpc-server no)
#(xend-unix-xmlrpc-server yes)
# Only enable xend-relocation-server on trusted networks as it lacks
# encryption and authentication.
#(xend-relocation-server no)
#(xend-relocation-ssl-server no)
#(xend-udev-event-server no)

#(xend-unix-path /var/lib/xend/xend-socket)


# Address and port xend should use for the legacy TCP XMLRPC interface,
# if xend-tcp-xmlrpc-server is set.
#(xend-tcp-xmlrpc-server-address 'localhost')
#(xend-tcp-xmlrpc-server-port 8006)

# SSL key and certificate to use for the legacy TCP XMLRPC interface.
# Setting these will mean that this port serves only SSL connections as
# opposed to plaintext ones.
#(xend-tcp-xmlrpc-server-ssl-key-file  /etc/xen/xmlrpc.key)
#(xend-tcp-xmlrpc-server-ssl-cert-file /etc/xen/xmlrpc.crt)


# Port xend should use for the HTTP interface, if xend-http-server is set.
#(xend-port            8000)

# Port xend should use for the relocation interface, if xend-relocation-server
# is set.
#(xend-relocation-port 8002)

# Port xend should use for the ssl relocation interface, if
# xend-relocation-ssl-server is set.
#(xend-relocation-ssl-port 8003)

# SSL key and certificate to use for the ssl relocation interface, if
# xend-relocation-ssl-server is set.
#(xend-relocation-server-ssl-key-file  /etc/xen/xmlrpc.key)
#(xend-relocation-server-ssl-cert-file  /etc/xen/xmlrpc.crt)

# Whether to use ssl as default when relocating.
#(xend-relocation-ssl no)

# Address xend should listen on for HTTP connections, if xend-http-server is
# set.
# Specifying 'localhost' prevents remote connections.
# Specifying the empty string '' (the default) allows all connections.
#(xend-address '')
#(xend-address localhost)

# Address xend should listen on for relocation-socket connections, if
# xend-relocation-server is set.
# Meaning and default as for xend-address above.
#(xend-relocation-address '')

# The hosts allowed to talk to the relocation port.  If this is empty (the
# default), then all connections are allowed (assuming that the connection
# arrives on a port and interface on which we are listening; see
# xend-relocation-port and xend-relocation-address above).  Otherwise, this
# should be a space-separated sequence of regular expressions.  Any host with
# a fully-qualified domain name or an IP address that matches one of these
# regular expressions will be accepted.
#
# For example:
#  (xend-relocation-hosts-allow '^localhost$ ^.*\\.example\\.org$')
#
#(xend-relocation-hosts-allow '')
(xend-relocation-hosts-allow '^localhost$ ^localhost\\.localdomain$')

# The limit (in kilobytes) on the size of the console buffer
#(console-limit 1024)

##
# To bridge network traffic, like this:
#
# dom0: ----------------- bridge -> real eth0 -> the network
#                            |
# domU: fake eth0 -> vifN.0 -+
#
# use
#
# (network-script network-bridge)
#
# Your default ethernet device is used as the outgoing interface, by default.
# To use a different one (e.g. eth1) use
#
# (network-script 'network-bridge netdev=eth1')
#
# The bridge takes on the ethernet device name by default.  To rename the
# bridge, use
#
# (network-script 'network-bridge bridge=<name>')
#
# It is possible to use the network-bridge script in more complicated
# scenarios, such as having two outgoing interfaces, with two bridges, and
# two fake interfaces per guest domain.  To do things like this, write
# yourself a wrapper script, and call network-bridge from it, as appropriate.
#
# SuSE users note:
# On openSUSE >= 11.1 and SLES >= 11, networks should be configured using
# native platform tool - YaST.  vif-bridge and qemu-ifup can be used to
# connect vifs to the YaST-managed networks.
#(network-script network-bridge)
(network-script )

# The script used to control virtual interfaces.  This can be overridden on a
# per-vif basis when creating a domain or a configuring a new vif.  The
# vif-bridge script is designed for use with the network-bridge script, or
# similar configurations.
#
# If you have overridden the bridge name using
# (network-script 'network-bridge bridge=<name>') then you may wish to do the
# same here.  The bridge name can also be set when creating a domain or
# configuring a new vif, but a value specified here would act as a default.
#
# If you are using only one bridge, the vif-bridge script will discover that,
# so there is no need to specify it explicitly.
#
(vif-script vif-bridge)


## Use the following if network traffic is routed, as an alternative to the
# settings for bridged networking given above.
#(network-script network-route)
#(vif-script     vif-route)


## Use the following if network traffic is routed with NAT, as an alternative
# to the settings for bridged networking given above.
#(network-script network-nat)
#(vif-script     vif-nat)

# dom0-min-mem is the lowest permissible memory level (in MB) for dom0.
# This is a minimum both for auto-ballooning (as enabled by
# enable-dom0-ballooning below) and for xm mem-set when applied to dom0.
(dom0-min-mem 512)

# Whether to enable auto-ballooning of dom0 to allow domUs to be created.
# If enable-dom0-ballooning = no, dom0 will never balloon out.
(enable-dom0-ballooning yes)

# In SMP system, dom0 will use dom0-cpus # of CPUS
# If dom0-cpus = 0, dom0 will take all cpus available
(dom0-cpus 0)

# Whether to enable core-dumps when domains crash.
#(enable-dump no)

# The tool used for initiating virtual TPM migration
#(external-migration-tool '')

# The interface for VNC servers to listen on. Defaults
# to 127.0.0.1  To restore old 'listen everywhere' behaviour
# set this to 0.0.0.0
#(vnc-listen '127.0.0.1')

# The default password for VNC console on HVM domain.
# Empty string is no authentication.
(vncpasswd '')

# The VNC server can be told to negotiate a TLS session
# to encryption all traffic, and provide x509 cert to
# clients enalbing them to verify server identity. The
# GTK-VNC widget, virt-viewer, virt-manager and VeNCrypt
# all support the VNC extension for TLS used in QEMU. The
# TightVNC/RealVNC/UltraVNC clients do not.
#
# To enable this create x509 certificates / keys in the
# directory /etc/xen/vnc
#
#  ca-cert.pem       - The CA certificate
#  server-cert.pem   - The Server certificate signed by the CA
#  server-key.pem    - The server private key
#
# and then uncomment this next line
# (vnc-tls 1)

# The certificate dir can be pointed elsewhere..
#
# (vnc-x509-cert-dir /etc/xen/vnc)

# The server can be told to request & validate an x509
# certificate from the client. Only clients with a cert
# signed by the trusted CA will be able to connect. This
# is more secure the password auth alone. Passwd auth can
# used at the same time if desired. To enable client cert
# checking uncomment this:
#
# (vnc-x509-verify 1)

# The default keymap to use for the VM's virtual keyboard
# when not specififed in VM's configuration
#(keymap 'en-us')

# Script to run when the label of a resource has changed.
#(resource-label-change-script '')

# Rotation count of qemu-dm log file.
#(qemu-dm-logrotate-count 10)

# Path where persistent domain configuration is stored.
# Default is /var/lib/xend/domains/
#
#(xend-domains-path /var/lib/xend/domains)

# Domain Locking
# In a multihost environment, domain locking prevents simultaneously
# running a domain on more than one host.
#
# If enabled, xend will execute a external lock utility (defined below)
# on each domain start and stop event.  Disabled by default.  Set to yes
# to enable domain locking.
#
#(xend-domain-lock no)

# Path where domain lock is stored if xend-domain-lock is enabled.
# Note:  This path must be accessible to all VM Servers participating
#        in domain locking, e.g. by specifying a shared mount point.
#        Lock is placed in /<xend-domain-lock-path>/<domain-uuid>.
# Default is /var/lib/xend/domains/
#
#(xend-domain-lock-path /var/lib/xend/domains)

# External locking utility called by xend for acquiring/releasing
# domain lock.  By default /etc/xen/scripts/domain-lock will be used
# if xend-domain-lock is set to yes.  Set to path of custom locking
# utility to override the default.
#
# Synopsis of lock-util:
# lock-util [-l|-u] -n <vm name> -i <vm uuid> -p <physical host> path"
# -l          Acquire (create) lock
# -u          Remove lock
# -n vm-name  Name of domain
# -i vm-id    Id or UUID of domain
# -p phy-host Name of physical host (dom0)
# path        /<xend-domain-lock-path>/<vm-uuid>
# Return 0 on success, non-zero on error.
#
# lock-util [-s] path"
# -s          Lock status.  If lock is acquired, print any contents
#             on stdout and return 0.  Return non-zero if lock is
#             available.
# path        /<xend-domain-lock-path>/<vm-uuid>
# If lock is acquired, print any contents on stdout and return 0.
# Return non-zero if lock is available.
#
# Default lock-util behavior:
# On domain start event, domain-lock will create and flock(1)
# /<xend-domain-lock-path>/<vm-uuid>/lock.  Every two seconds it
# will write <vm-name>, <vm-id>, <vm-host>, and <tick> to the lock.
# <tick> is running counter.
# On domain stop event, domain-lock will unlock and remove
# /<xend-domain-lock-path>/<vm-uuid>/lock.
#
# Note: If xend-domain-lock-path is a cluster-unaware file system,
#       administrator intervention may be required to remove stale
#       locks.  Consider two hosts using NFS for xend-domain-lock-path
#       when HostA, running vm1, crashes.  HostB could not acquire a
#       lock for vm1 since the NFS server holds an exclusive lock
#       acquired by HostA.  The lock file must be manually removed
#       before starting vm1 on HostA.
#
#(xend-domain-lock-utility domain-lock)