XEN: миграция доменов с ARCH (XEN 3*) на Gentoo (XEN 4*) - Booting from Hard Disk... Boot failed: not a bootable disk
gebs 14 ноября, 2012 - 13:56
Здравствуйте седобородые гуру. Встала мега задача. Разгребсти гуано с виртуалками. Так как копаться в грязном белье не комильфо, было решено всё поднять заново на моей любимой системе.
Поднял app-emulation/xen-4.1.1-r2 на 3.5.7-gentoo #2 SMP Wed Nov 14 08:10:25 MSK 2012 x86_64 STABLE , скопировал с АРЧА обрызы виртуалок, при попытке запустить HVM домен - вижу в VNC Viewer: Booting from Hard Disk... Boot failed: not a bootable disk Помогите мнением и, возможно, решением. Спасибо.
ДопИнфо:
root@localhost$ xl info | grep cap hw_caps : bfebfbff:20100800:00000000:00000940:0000e3bd:00000000:00000001:00000000 virt_caps : hvm xen_caps : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64
cat ./qemu-dm-web.log
http://pastebin.com/icr2Zknr
cat xen-hotplug.log
can't add tap7.0 to bridge eth1: Operation not supported
cat xl-web.log
Waiting for domain web (domid 7) to die [pid 3281] Domain 7 is dead Action for shutdown reason code 0 is destroy Domain 7 needs to be cleaned up: destroying the domain Done. Exiting now
Конфиг:
root@localhost $cat config.hvm
kernel = "/usr/lib/xen/boot/hvmloader" builder='hvm' memory = 768 name = "web" vcpus=2 pae=1 acpi=1 vif= ['type=ioemu,bridge=eth1,mac=AC:16:3e:AB:00:12'] disk = ['file:/etc/xen/vm_web/web1_new.img,hda,w'] device_model = '/usr/lib64/xen/bin/qemu-dm' boot="c" sdl=0 opengl=1 vnc=1 vnclisten="0.0.0.0" vncdisplay=17 vncpasswd='' stdvga=0 serial='pty'
»
- Для комментирования войдите или зарегистрируйтесь
далее предполагается, что *
далее предполагается, что
* ядро собрано корректно с т.з xen dom0; поддержка bridge и tun - включена
* app-emulation/xen-tools построны с USE xend
* все повествуется в контексте app-emulation/xen|xen-tools 4.1.2
у меня сделано так (не нравится, как в 4.1 работает xl, поэтому остаюсь на xm/xend. для того, чтобы жить с xl, лучше перейти на xen 4.2):
1. мост для xen строится стандартным для gentoo способом, а не через xend (так мне кажется надежнее и совпадает с мнением wiki xen), т.е посредством /etc/conf.d/net (например, в моей конфигурации используется транк двух физических ethernet, скриптами xend это сделать проблематично):
2. старт демонов xen dom0 вынесен в /etc/local.d (прежде всего потому что время от времени эту же систему нужно грузить без xen, например, чтобы обновиться. используется функциональность openrc - если rc_sys не определена в /etc/rc.conf, то openrc сам выставляет ее значение)
[/etc/local.d/xen.start]
как видно, в скрипте строится еще один мост, для виртуальной сети (между domU), никак не связанной с внешним миром (понятно, что можно убрать, если не надо)
с такой конфигурацией у вас все должно заработать, только в конфигурации вашего hvm domU, в секции vif, нужно заменить bridge=eth1 на bridge=xenbr
Спасибо за ответ. Без
Спасибо за ответ. Без поддержки xend, попробую собрать с поддержкой и обновить до версии 4.2 но это будет собираться только с .keyword ~amd64, то есть из нестабильной ветки.
gebs написал(а): Без
вы неверно интерпретируете написанное:
если нужно то, что формально stable - ставьте 4.1.1 с xend (и прочими use, нужными вашим domU)
xl (даже тот, который stable в 4.1) еще не допилен до production, и сейчас активно "пилится". в 4.2 - уже лучше (замечу, кстати, что в portage 4.2 еще нет, но xen любой версии достаточно просто собирается руками, а при желании - не сложно смастерить ebuild себе в локальный оверлей)
однако для небольших инсталляций (вы ведь не amazon и не linode, правда? :) ветка 4.1 вполне подходит, поэтому в планах разработчиков xen есть 4.1.3, а может быть, и 4.1.4 родится
xl будет развиваться также, как и в старшей ветке. кстати, в 4.2 xm/xend уже deprecated
еще немного о стабильности: stable для xen в gentoo - штука условная, при возникновении проблемы не ebuild, а касающейся работы функциональности xen, xen-tools или ядра, в "нашей", т.е gentoo bugzill-e вас все равно отправят upstream
текущая проблема, из-за чего родился пост - всего лишь в сетевой конфигурации вашего domU (ну, может еще в конфигурации ядра dom0)
vr13 написал(а):gebs
gebs написал(а): vr13
root@ozweb
root@localhost fdisk -l web1_new.img
virt-sysrep prepare
virt-sysrep prepare foo-bla.img .....
Compute:
Bosch M2.8.1 -> custom Bosch M2.8.3 clone from Russia.
Speed about 260 km,Ram 2 pers.,HDD - 70 kg,210 FLOPS ;)
Slepnoga, благодарю за
Slepnoga, благодарю за участие в дискуссии, но данный данная утилита у меня не установлена. При попытке установит:
Да и для чего собственно это нужно делать?
Вернусь к прошлым обсуждениям:
пересобрал xen с флагами xend, pae; запустил xend; имею:
root@localhost cat qemu-dm-web.log
http://pastebin.com/92RNDgMu
И собственно после запуска:
root@localhost xm create webcfg
Using config file "./webcfg".
Error: Device 0 (vif) could not be connected. Hotplug scripts not working.
P.S
Цитата: В частности
tap - это интерфейс, работающий поверх другого интерфейса. пока можно больше ничего не говорить про него. а вот eth1 - это в вашем случае что - мост или просто интерфейс?
в первом посте говорилось, что xen-овский hotplug лучше не использовать, а создавать сетевую инфраструктуру инсталляции средствами baselayout2. соответственно в /etc/xen/xend-config.sxp закомментировать все, что связано с сетью, ниже этого комментария:
более подробно - посмотрите тут http://wiki.xen.org/wiki/Network_Configuration_Examples_%28Xen_4.1%2B%29
Ну нет так нет. П.С тебя
Ну нет так нет.
П.С тебя пугает ~amd64 ? Так сия утиль в ближайшие пол-года не позеленеет ;)
Compute:
Bosch M2.8.1 -> custom Bosch M2.8.3 clone from Russia.
Speed about 260 km,Ram 2 pers.,HDD - 70 kg,210 FLOPS ;)
gebs
а это все, что он показывает? в моем случае (винда, как говорилось ранее, - hvm, freebsd - pv. в обоих случаях это именно образ диска, а не просто partition, как делается в случае pv linux. fdisk это распознает и говорит, соответственно:
образы записаны в томах lvm, но это в данном случае неважно. винда грузится, как в вашем случае hvmloader, а freebsd - через pygrub
а это все, что он
Да, что в общем-то странно. eth1 - это физический интерфейс. Но в любом случае спасибо за информацию.