Xen dom0 не грузится [solved] (как бы просмотреть лог загрузки?)

[Poor Fred]

Собрал ядро 2.6.31-xen-r11 по статье на http://en.gentoo-wiki.com/wiki/Xen. Но ядро грузится наполовину. Сначала быстро мелькают строки с [XEN], потом все останавливается после строк:

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

console [tty0] enabled
console [xvc-1] enabled

Клавиатура не отвечает, перезагрузка только ресетом.

Как бы просмотреть, что там делается, т.к. /var/log/dmesg затирается после следующей загрузки, а xend, судя по всему даже и не стартует?

[vr13]

это не "наполовину", это в самом начале загрузки dom0: судя по моему логу, до этого сообщения - только инициализация памяти и частично acpi/dma. думаю, что чего-то недоконфигурировали в ядре dom0, ну или что-то не то с железом/настройками в bios. про консоль - тоже не совсем верно, посмотрите на эту информацию (pdf), хотя к зависанию приводить не должно - будет просто сумбур на экране. у меня в grub.conf так:

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

  root (hd0,0)
  kernel /boot/xen-3.4.2-x86_64.gz console=vga xencons=off <пропущена специфика> vga=mode-0x0317,keep
  module /boot/kernel64-xen0 root=/dev/md3 ro <пропущена специфика> quiet console=tty1

ядро - тоже 2.6.31-xen-r11 (x86_64, но проверял и x86 - работает вроде как)

[vr13]

проверил: xen-sources-2.6.31-r11 (dom0) на x86 работает без проблем. прикреплен .config, а также листинги dmesg и xm dmesg

в конфигурации есть ноутбучная экзотика - bluetooth, wifi (i3945), а также сконфигурирован suspend2ram. конфигурация делалась обычным способом - make silentoldconfig на .config gentoo-sources-2.6.31-r10 и последующую правку через меню для соответствия xen-dom0

app-emulation/xen - stable (3.4.2), собран, разумеется, с pae

[Poor Fred]

проверил: xen-sources-2.6.31-r11 (dom0) на x86 работает без проблем. прикреплен .config, а также листинги dmesg и xm dmesg

Огромное спасибо, попробую. Попытался по всякому - и xen до 3,4,0 даунгрейдил, и ядро новое взял 2.6.33-xen - без толку. С последним так вообще экран на каком-то этапе гаснет и вообще хз что там делается.

[vr13]

на x86 2.6.31-r11 обнаружилась-таки проблема: не работает blktap - это если образы дисков domU хранить в файлах dom0 (или драйвер-домена), и при этом не хотеть отдавать их гостевым машинам, смонтированными через loopback (т.е вместо конструкции disk = [ 'file:/.../domUdisk..., использовать disk = [ 'tap:aio:/.../domUdisk... ). в 2.6.29-xen-r4 и ранее это точно работало

на x86_64 не проверял: там делалось, как мне кажется, более "по-взрослому": диски domU это тома lvm2 dom0 и, соответственно, видятся как disk = [ 'phy:/dev/xenimages.... следовательно, blktap backend driver вообще не нужен

[Poor Fred]

проверил: xen-sources-2.6.31-r11 (dom0) на x86 работает без проблем. прикреплен .config, а также листинги dmesg и xm dmesg

Заработало. Похоже, проблема в CONFIG_HZ=300 (у меня было 1000) и/или CONFIG_XEN_SCRUB_PAGES (у меня было включено).

Зато другая проблема. Nvidia-drivers не собираются, nouveau под .31-м не работает, пришлось собрать .33-е. В нем консоль заработала, а вот X-ы - нет.

[vr13]

проверил: xen-sources-2.6.31-r11 (dom0) на x86 работает без проблем. прикреплен .config, а также листинги dmesg и xm dmesg

Заработало. Похоже, проблема в CONFIG_HZ=300 (у меня было 1000) и/или CONFIG_XEN_SCRUB_PAGES (у меня было включено).

scrub_pages - к загрузке отношения точно не имеет. это для безопасности, вроде как - чистить память domU после завершения его работы или не чистить

Зато другая проблема. Nvidia-drivers не собираются, nouveau под .31-м не работает, пришлось собрать .33-е. В нем консоль заработала, а вот X-ы - нет.

попробуйте это, мне помогает. правда, современные proprietary nvidia drivers на эту уловку не поддаются, и все равно не собираются, поэтому использую x11-drivers/nvidia-drivers-173.14.22. чтобы собрать, нужно создать этот софтлинк и

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

IGNORE_XEN_PRESENCE=y emerge nvidia-drivers

на x86 2.6.31-xen-r11 - проверялось. если сможете перехитрить современные nvidia - сообщите, pls: мне интересно, но копаться в makefiles желания нет. в ссылке выше, я вроде бы объяснил, для чего создается линк. там и надо копать

[Poor Fred]

попробуйте это, мне помогает.

Ага, собрались. Только вот работать все равно не хотят:

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

(EE) NVIDIA(0): Failed to initialize the NVIDIA graphics device PCI:2:0:0.
(EE) NVIDIA(0):     Please see the COMMON PROBLEMS section in the README for
(EE) NVIDIA(0):     additional information.
(EE) NVIDIA(0): Failed to initialize the NVIDIA graphics device!

Запустил с nv, ФПС низкий, да и фиг с ним пока.

В доке написано добавить noapic либо pci=noacpi, еще пара команд, но с ними ядро ругается.
Подозреваю, что дело в бэкендах и фронтендах PCI Xen, но т.к. я не совсем понимаю что там что, трогать побаиваюсь.

И сразу еще один вопрос, глобальный. Когда тема виртуализации появилась, я мечтал, что смогу держать одновременно запущенными линукс и винду. Последняя для игрушек исключительно, в том числе "тяжелых". В последнее время я стал подозревать, что это нереально и что никакого 3D в госте я не получу. Это так?

[vr13]

про nvidia ничего сказать не могу: у меня на ноутбуке - работает. другого ничего никогда не пробовал. разве что могу свой, толькочтошный, Xorg.0.log показать:
http://pastebin.com/yvzuKaqi

...
В доке написано добавить noapic либо pci=noacpi, еще пара команд, но с ними ядро ругается.
Подозреваю, что дело в бэкендах и фронтендах PCI Xen, но т.к. я не совсем понимаю что там что, трогать побаиваюсь.

нет, не так: в случае винды (и любого hvm domU), xen выполняет полную виртуализацию (hvm - hardware virtual machine), которую фактически реализует qemu, включенный в состав xen-tools, и связь такого domU с dom0 минимальна - разве что убить процесс qemu. гипервизор xen при этом освободит захваченные ресурсы. qemu организует набор устройств: дисковый адаптер, сетевой адаптер, видеоадаптер, которыми hvm domU пользуется, как если бы они были настоящими. я не помню (в общем, никогда не пытался запомнить, т.к не надо было), что это за устройства, но разумеется, они достаточно примитивные для 3D или какой-л нормальной производительности (см содержимое логов в /var/log/xen/qemu*). интересность xen заключается не в hvm, а в pv (паравиртуальных) domU, которые "знают" что работают под управлением гипервизора, и работают много эффективнее. в этом случае все устроено так: dom0 поддерживает драйвер реального устройства, на dom0 также работает т.н backend драйвер, который может взаимодействовать с реальным драйвером, с одной стороны, и с гипервизором - с другой. со стороны domU есть frontend driver, который взаимодействует через гипервизор с соответствующим backend-драйвером. т.е на схема выглядит так domU <-> frontend drv <-> xen <-> backend drv <-> dom0 <-> physical device. понятно, что пар frontend-backend столько, сколько domU и устройств на них. этот уровень абстракции сделан, чтобы максимально изолировать виртуальные машины (domU) xen от физического железа. теоретически, указанным способом любой драйвер, который поддерживается dom0, можно связать с одним или несколькими domU. на практике, правда, есть множество ограничений. замечу, что выше дано очень примитивное описание - на самом деле, все, конечно сложнее

существуют попытки заставить винду быть паравиртуальной, мне известна одна - драйверы James Harper'a - когда-то я пробовал - действительно виндовый domU работает быстрее. если интересно - могу порассказывать что тогда получалось

И сразу еще один вопрос, глобальный. Когда тема виртуализации появилась, я мечтал, что смогу держать одновременно запущенными линукс и винду. Последняя для игрушек исключительно, в том числе "тяжелых". В последнее время я стал подозревать, что это нереально и что никакого 3D в госте я не получу. Это так?

очень сомнительно, что вы получите виртуальную винду с нормальным внешним видом и производительностью для игр. можно попробовать конечно, сделать виндовый домен, работающий через sdl-графику (вместо vnc). все равно, вряд-ли будет приемлемо. попробуйте virtualbox, он, говорят, лучше для таких целей. xen - в основном, для серверных применений (я использую, например, для имитации всевозможных кластерных конфигураций: удобно, когда под столом работает 15 машин с postgresql, ну или 5 с ораклом )

в настоящее время появилась еще одна тенденция, которую поддерживает xen - это виртуализация i/o. у intel это называется vt-d, что-то похожее есть у amd. идея состоит в том, что pci/pcie устройство передается целиком domU (iommu dmar re-mapping), в т.ч hmv domU - в вашем случае, скажем, фактически аппаратная передача nvidia карты виртуальной винде со всеми вытекающими 3D
проблема в том, что существующее железо либо очень дорогое для таких игр (серверное железо, строго говоря), либо - очень капризное (см http://wiki.xensource.com/xenwiki/VTdHowTo), и тоже, кстати, не дешевое

кстати, на http://xgu.ru/wiki/Linux_в_Xen довольно много про xen по-русски. может быть будет интересно

[Poor Fred]

существуют попытки заставить винду быть паравиртуальной, мне известна одна - драйверы James Harper'a - когда-то я пробовал - действительно виндовый domU работает быстрее. если интересно - могу порассказывать что тогда получалось

Читал на xgu.ru. Либо невозможно, либо требует модифицированную ОС.

очень сомнительно, что вы получите виртуальную винду с нормальным внешним видом и производительностью для игр. можно попробовать конечно, сделать виндовый домен, работающий через sdl-графику (вместо vnc). все равно, вряд-ли будет приемлемо. попробуйте virtualbox,

Я пробовал qemu+kqemu - не понравилось. qemu+kmv - разницы не заметил. Теперь вот пробую Xen, оказывается почти то же самое. Virtualbox использую давно и пожалуй да, он самый удобный.
Разочарован немного. Я ожидал большего. Несколько серверных ОС это здорово и может пригодиться, но у меня были другие планы. Но все равно - огромное спасибо.

Да, xgu.ru читал, но там не было ответов на некоторые вопросы, очевидные для всех, кроме меня, видимо.

[Poor Fred]

Еще проблемка осталась.

В domU нет клавиатуры и мыши. Клавиатура PS/2, мышь USB. Сначала грешил на tigervnc, сменил на tightvnc - проблема осталась. Теперь, думаю, проблема либо в ядре, либо в самом Xen. Xen был собран с такими флагами:

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

[ebuild   R   ] app-emulation/xen-tools-3.4.2  USE="hvm screen -acm -api -custom-cflags -debug -doc -flask -pygrub" 0 kB
[ebuild   R   ] app-emulation/xen-3.4.2-r1  USE="pae -acm -custom-cflags -debug -flask -xsm" 0 kB

Может быть ему чего-то не хватает?

Гугление ничего не дало, кроме проблем с раскладками клавиатуры.

[vr13]

если вы про виндовый домен, то у меня так:

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

kernel = "/usr/lib/xen/boot/hvmloader"
builder='hvm'
memory = 1024
shadow_memory = 8
name = "winxp"
localtime=1
vcpus=2
apic=1
acpi=1
vif = [ 'mac=00:11:22:33:44:55' ]
disk = [ 'phy:/dev/xen-img/winxp,hda,w' ]
device_model = '/usr/lib/xen/bin/qemu-dm'
boot="dcn"
on_poweroff = 'destroy'
sdl=0
vnclisten='0.0.0.0'
vncpasswd='winxp'
vnc=1
opengl=1
usb=1
usbdevice = "tablet"

на сеть и диск внимания не обращайте - у меня как раз эти самые pv-драйверы для windows установлены

[Poor Fred]

если вы про виндовый домен,

Не, совершенно без разницы, какой домен, просто в vncviewer вообще ничего не вводится и мышь не лочится. Как будто я его запустил с параметром -viewonly. Вот конфиг, кстати:

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

kernel = "/usr/lib/xen/boot/hvmloader"
builder='hvm'
memory = 1024
shadow_memory = 8
name = "freebsd7"
vif = [ 'type=ioemu, bridge=xenbr0, mac=00:16:3e:03:00:c3' ]
disk = [ 'file:/home/xen/debian.img,hda,w', 'file:/home/public/Distros/FreeBSD-7.2/7.2-RELEASE-i386-dvd1.iso,hdc:cdrom,r' ]
device_model = '/usr/lib/xen/bin/qemu-dm'
boot="d"
sdl=0
vnc=1
vncpasswd=''
stdvga=0
serial='pty'
usb=1
keymap='ru'
vncdisplay=1
apic=1
acpi=1

[vr13]

мне кажется, нужно сказать vncconsole=1 (вместо vncdisplay) - там консоль нужно имитировать, а не графику
мышь, это как раз usb=1; usbdevice='tablet'

в /etc/xen есть несколько примеров с комментариями (xmexample*). use флаги непричем: vnc server (как впрочем и sdl support) - неотъемлемая часть xen-tools

[Poor Fred]

Krdc подключается, работают и мышь и клавиатура. В Tightvnc - не хотят. Значит проблема, похоже, в vnc-клиенте.

Так что можно сказать, что проблема решена. Спасибо за участие.