Re: [Xen-devel] handling local attach of phy disks for pygrub (Was: Xen 4.3 xl migrate " htree_dirblock_to_tree" on second host)

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

Please could you not top post.

On Wed, 2014-02-12 at 02:48 +0000, Miguel Clara wrote:
> Parsing config from test.cfg
> libxl: debug: libxl_create.c:1230:do_domain_create: ao 0x9a9f30: create: 
> how=(nil) callback=(nil) poller=0x9a9f90
> libxl: debug: libxl_device.c:257:libxl__device_disk_set_backend: Disk 
> vdev=xvda spec.backend=unknown
> libxl: debug: libxl_device.c:188:disk_try_backend: Disk vdev=xvda, uses 
> script=... assuming phy backend
> libxl: debug: libxl_device.c:296:libxl__device_disk_set_backend: Disk 
> vdev=xvda, using backend phy
> libxl: debug: libxl_create.c:675:initiate_domain_create: running bootloader
> libxl: debug: libxl_device.c:257:libxl__device_disk_set_backend: Disk 
> vdev=(null) spec.backend=phy
> libxl: debug: libxl_device.c:188:disk_try_backend: Disk vdev=(null), uses 
> script=... assuming phy backend
> libxl: debug: libxl.c:2604:libxl__device_disk_local_initiate_attach: locally 
> attaching PHY disk drbd-remus-test
> 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/local/lib/xen/bin/pygrub
> libxl: debug: libxl_create.c:1243:do_domain_create: ao 0x9a9f30: inprogress: 
> poller=0x9a9f90, flags=i
> libxl: debug: libxl_event.c:559:libxl__ev_xswatch_register: watch w=0x9aa3c8 
> wpath=/local/domain/35 token=3/0: register slotnum=3
> libxl: debug: libxl_event.c:1737:libxl__ao_progress_report: ao 0x9a9f30: 
> progress report: ignored
> libxl: debug: libxl_bootloader.c:535:bootloader_gotptys: executing 
> bootloader: /usr/local/lib/xen/bin/pygrub
> libxl: debug: libxl_bootloader.c:539:bootloader_gotptys:   bootloader arg: 
> /usr/local/lib/xen/bin/pygrub
> libxl: debug: libxl_bootloader.c:539:bootloader_gotptys:   bootloader arg: 
> --args=root=/dev/xvda1 rw console=hvc0 xencons=tty
> libxl: debug: libxl_bootloader.c:539:bootloader_gotptys:   bootloader arg: 
> --output=/var/run/xen/bootloader.35.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.35.d
> libxl: debug: libxl_bootloader.c:539:bootloader_gotptys:   bootloader arg: 
> drbd-remus-test
> libxl: debug: libxl_event.c:503:watchfd_callback: watch w=0x9aa3c8 
> wpath=/local/domain/35 token=3/0: event epath=/local/domain/35
> libxl: error: libxl_bootloader.c:628:bootloader_finished: bootloader failed - 
> consult logfile /var/log/xen/bootloader.35.log
> libxl: error: libxl_exec.c:118:libxl_report_child_exitstatus: bootloader 
> [12781] exited with error status 1
> libxl: debug: libxl_event.c:596:libxl__ev_xswatch_deregister: watch 
> w=0x9aa3c8 wpath=/local/domain/35 token=3/0: deregister slotnum=3
> libxl: error: libxl_create.c:900:domcreate_rebuild_done: cannot (re-)build 
> domain: -3
> libxl: debug: libxl_event.c:1569:libxl__ao_complete: ao 0x9a9f30: complete, 
> rc=-3
> libxl: debug: libxl_event.c:1541:libxl__ao__destroy: ao 0x9a9f30: destroy
> xc: debug: hypercall buffer: total allocations:20 total releases:20
> xc: debug: hypercall buffer: current allocations:0 maximum allocations:2
> xc: debug: hypercall buffer: cache current size:2
> xc: debug: hypercall buffer: cache hits:16 misses:2 toobig:2
> 
> 
> This part:
> libxl: debug: libxl_bootloader.c:539:bootloader_gotptys:   bootloader arg: 
> drbd-remus-test
> 
> Does seem weird...

Indeed, especially when there is a preceding
libxl: debug: libxl.c:2604:libxl__device_disk_local_initiate_attach: locally 
attaching PHY disk drbd-remus-test
which should have resulted in an xvda device to use.

Hrm, that function handles phy devices as a straight passthrough of the
underlying device, which is the source of the error.

I wonder if we should add some special handling of disk devices which
have a non-null script. I guess that would look something like the QDISK
bit of libxl__device_disk_local_initiate_attach but gated on
disk->script rather than ->format. i.e.:
        case LIBXL_DISK_BACKEND_PHY:
                if (disk->script) {
                libxl__prepare_ao_device(ao, &dls->aodev);
                dls->aodev.callback = local_device_attach_cb;
                device_disk_add(egc, LIBXL_TOOLSTACK_DOMID, disk,
                                &dls->aodev, libxl__alloc_vdev,
                                (void *) blkdev_start);
                return;
            } else {
                dev = disk->pdev_path;
            }

Would also need some code in libxl__device_disk_local_initiate_detach.
Ian.


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