Re: [Xen-users] xl stack problems on CentOS6 XEN4

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Tue, 2015-05-12 at 10:18 +0000, Hildebrand, Nils (BIT II 9) wrote:
> Hi Ian,
> 
> XEN-rpm is 4.4.1-10 which corresponds to the output of "xl info" 
> (xen-version).
> 
> Here is the debug-output of xl  -vvv create (without doing my pre-startup 
> workaround):
> 
> libxl: debug: libxl_create.c:1342:do_domain_create: ao 0x17c0170: create: 
> how=(nil) callback=(nil) poller=0x17c01d0
> libxl: debug: libxl_device.c:251:libxl__device_disk_set_backend: Disk 
> vdev=xvda spec.backend=unknown
> libxl: debug: libxl_device.c:189:disk_try_backend: Disk vdev=xvda, uses 
> script=... assuming phy backend
> libxl: debug: libxl_device.c:286:libxl__device_disk_set_backend: Disk 
> vdev=xvda, using backend phy
> libxl: debug: libxl_create.c:797:initiate_domain_create: running bootloader
> libxl: debug: libxl_device.c:251:libxl__device_disk_set_backend: Disk 
> vdev=(null) spec.backend=phy
> libxl: debug: libxl_device.c:189:disk_try_backend: Disk vdev=(null), uses 
> script=... assuming phy backend
> libxl: debug: libxl.c:2635:libxl__device_disk_local_initiate_attach: locally 
> attaching PHY disk xlnur079
> libxl: debug: libxl_bootloader.c:409:bootloader_disk_attached_cb: Config 
> bootloader value: pygrub
> libxl: debug: libxl_bootloader.c:425:bootloader_disk_attached_cb: Checking 
> for bootloader in libexec path: /usr/lib64/xen/bin/pygrub
> libxl: debug: libxl_create.c:1356:do_domain_create: ao 0x17c0170: inprogress: 
> poller=0x17c01d0, flags=i
> libxl: debug: libxl_event.c:570:libxl__ev_xswatch_register: watch w=0x17b61e8 
> wpath=/local/domain/54 token=3/0: register slotnum=3
> libxl: debug: libxl_event.c:1761:libxl__ao_progress_report: ao 0x17c0170: 
> progress report: ignored
> libxl: debug: libxl_bootloader.c:535:bootloader_gotptys: executing 
> bootloader: /usr/lib64/xen/bin/pygrub
> libxl: debug: libxl_bootloader.c:539:bootloader_gotptys:   bootloader arg: 
> /usr/lib64/xen/bin/pygrub
> libxl: debug: libxl_bootloader.c:539:bootloader_gotptys:   bootloader arg: 
> --args= text vga=normal selinux=0
> libxl: debug: libxl_bootloader.c:539:bootloader_gotptys:   bootloader arg: 
> --output=/var/run/xen/bootloader.54.out
> libxl: debug: libxl_bootloader.c:539:bootloader_gotptys:   bootloader arg: 
> --output-format=simple0
> libxl: debug: libxl_bootloader.c:539:bootloader_gotptys:   bootloader arg: 
> --output-directory=/var/run/xen/bootloader.54.d
> libxl: debug: libxl_bootloader.c:539:bootloader_gotptys:   bootloader arg: 
> xlnur079
> libxl: debug: libxl_event.c:514:watchfd_callback: watch w=0x17b61e8 
> wpath=/local/domain/54 token=3/0: event epath=/local/domain/54
> libxl: error: libxl_bootloader.c:628:bootloader_finished: bootloader failed - 
> consult logfile /var/log/xen/bootloader.54.log
> libxl: error: libxl_exec.c:118:libxl_report_child_exitstatus: bootloader [-1] 
> exited with error status 1
> libxl: debug: libxl_event.c:606:libxl__ev_xswatch_deregister: watch 
> w=0x17b61e8 wpath=/local/domain/54 token=3/0: deregister slotnum=3
> libxl: error: libxl_create.c:1022:domcreate_rebuild_done: cannot (re-)build 
> domain: -3
> libxl: debug: libxl_event.c:1591:libxl__ao_complete: ao 0x17c0170: complete, 
> rc=-3
> libxl: debug: libxl_event.c:1563:libxl__ao__destroy: ao 0x17c0170: destroy
> xc: debug: hypercall buffer: total allocations:28 total releases:28
> xc: debug: hypercall buffer: current allocations:0 maximum allocations:2
> xc: debug: hypercall buffer: cache current size:2
> xc: debug: hypercall buffer: cache hits:24 misses:2 toobig:2
> Parsing config from xlnur079

> 
> xl create -n shows in the disk-section:  "script": "block-drbd"

That's good/expected.

> So yes - it seems that during (real?) creation the xl-parser does not
> seem to get the right disk-device-type and assumes "phy" instead of
> "drbd".

phy is correct, I think. the drdb: prefix translates into the use of the
block-drdb script which is supposed to make the device available to
dom0.

Xen doesn't provide block-drdb, I think it comes from the drdb project
itself. It's possible that something in libxl is incompatible with that
3rd party script, although I'm sure I've heard rumours of it working
(perhaps not with pygrub?).

http://lists.xen.org/archives/html/xen-devel/2014-02/msg01190.html might
be relevant here.

I take it that "xlnur079" is the "vmname" from:
        disk = [ âdrbd:vmname,xvda,wâ ]
?

It seems that pygrub is being invoked onto xlnur079 directly, whereas I
would have expected the drdb script to have mapped that into some device
or other under /dev/. Perhaps updating the script will make that work
properly?

TBH, I'm struggling to find the code which invokes the script in this
pygrub case. If updating your block-drdb (per that link) doesn't help
then it seems possible you've found a deficiency in the libxl
arrangements here :-( If that turns out to be the case please could you
post that as a bug report to the xen-devel list.
http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen

Thanks,
Ian.


_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxx
http://lists.xen.org/xen-users