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

[Roger Pau Monnà <roger.pau@xxxxxxxxxx>]

On 12/02/14 10:56, Ian Campbell wrote:
> 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.

I though this was already working on libxl... Could you please test the 
attached patch? Which is basically the chunk Ian posted above plus the 
libxl__device_disk_local_initiate_detach part.

---
commit 3bcf91cbbd9a18db9ae7d594ffde7979774ed512
Author: Roger Pau Monne <roger.pau@xxxxxxxxxx>
Date:   Wed Feb 12 11:15:17 2014 +0100

    libxl: local attach support for PHY backends using scripts
    
    Allow disks using the PHY backend to locally attach if using a script.
    
    Signed-off-by: Roger Pau Monnà <roger.pau@xxxxxxxxxx>
    Suggested-by: Ian Campbell <ian.campbell@xxxxxxxxxx>

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 730f6e1..5cb46a1 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -2630,6 +2630,16 @@ void libxl__device_disk_local_initiate_attach(libxl__egc 
*egc,
 
     switch (disk->backend) {
         case LIBXL_DISK_BACKEND_PHY:
+            if (disk->script != NULL) {
+                LOG(DEBUG, "trying to locally attach PHY device %s with script 
%s",
+                           disk->pdev_path, 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;
+            }
             LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "locally attaching PHY disk %s",
                        disk->pdev_path);
             dev = disk->pdev_path;
@@ -2709,7 +2719,7 @@ static void local_device_attach_cb(libxl__egc *egc, 
libxl__ao_device *aodev)
     }
 
     dev = GCSPRINTF("/dev/%s", disk->vdev);
-    LOG(DEBUG, "locally attaching qdisk %s", dev);
+    LOG(DEBUG, "locally attached disk %s", dev);
 
     rc = libxl__device_from_disk(gc, LIBXL_TOOLSTACK_DOMID, disk, &device);
     if (rc < 0)
@@ -2749,6 +2759,7 @@ void libxl__device_disk_local_initiate_detach(libxl__egc 
*egc,
     if (!dls->diskpath) goto out;
 
     switch (disk->backend) {
+        case LIBXL_DISK_BACKEND_PHY:
         case LIBXL_DISK_BACKEND_QDISK:
             if (disk->vdev != NULL) {
                 GCNEW(device);
@@ -2766,7 +2777,6 @@ void libxl__device_disk_local_initiate_detach(libxl__egc 
*egc,
             /* disk->vdev == NULL; fall through */
         default:
             /*
-             * Nothing to do for PHYSTYPE_PHY.
              * For other device types assume that the blktap2 process is
              * needed by the soon to be started domain and do nothing.
              */





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