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

["Hildebrand, Nils (BIT II 9)" <Nils.Hildebrand@xxxxxxxxxxx>]

Hi Roger,

we now had the chance to test the patch against 4.4.2-4 (which came in in the 
meantime).
It seems to work!

What I tested so far:

xl create without switching drbd to primary - works now.

reboot within the DomU - works now

xl reboot - works now.

Should I do some further testing, or can you give the green light to roll out 
the patch in the mainline CentOS 6 XEN 4 project?
The official 4.4.2-4 still fails at xl create if I do not switch drbd to 
primary and go to /dev/drbd/by-res/ before issuing xl create).


Kind regards

Nils



  

-----Ursprüngliche Nachricht-----
Von: Roger Pau Monné [mailto:roger.pau@xxxxxxxxxx] 
Gesendet: Donnerstag, 21. Mai 2015 15:41
An: Hildebrand, Nils (BIT II 9)
Cc: 'xen-users@xxxxxxxxxxxxx'; Ian Campbell
Betreff: Re: [Xen-users] xl stack problems on CentOS6 XEN4

El 21/05/15 a les 14.12, Hildebrand, Nils (BIT II 9) ha escrit:
> Hi Roger,
> 
> your patch does not seem to fit my sources:
> http://vault.centos.org/6.6/xen4/Source/SPackages/
> I am currently on XEN 4.4.2-2 (=CentOS 6 XEN 4)- your patch is for 4.5?
>  
> Can you please backport your patch to 4.4.2-2?

Please don't top post.

Patch applied cleanly against stable-4.4 branch. Below is the patch 
against the stable-4.4 branch.

Roger.
---
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 59e3292..ed30ee2 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -2630,9 +2630,16 @@ void libxl__device_disk_local_initiate_attach(libxl__egc 
*egc,
 
     switch (disk->backend) {
         case LIBXL_DISK_BACKEND_PHY:
-            LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "locally attaching PHY disk %s",
-                       disk->pdev_path);
-            dev = disk->pdev_path;
+            if (disk->script == NULL) {
+                LOG(DEBUG, "locally attaching PHY disk %s", disk->pdev_path);
+                dev = disk->pdev_path;
+            } else {
+                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;
+            }
             break;
         case LIBXL_DISK_BACKEND_TAP:
             switch (disk->format) {
@@ -2709,7 +2716,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 attaching disk %s", dev);
 
     rc = libxl__device_from_disk(gc, LIBXL_TOOLSTACK_DOMID, disk, &device);
     if (rc < 0)
@@ -2750,6 +2757,7 @@ void libxl__device_disk_local_initiate_detach(libxl__egc 
*egc,
 
     switch (disk->backend) {
         case LIBXL_DISK_BACKEND_QDISK:
+        case LIBXL_DISK_BACKEND_PHY:
             if (disk->vdev != NULL) {
                 GCNEW(device);
                 rc = libxl__device_from_disk(gc, LIBXL_TOOLSTACK_DOMID,
@@ -2766,7 +2774,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-users mailing list
Xen-users@xxxxxxxxxxxxx
http://lists.xen.org/xen-users