[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-users] HVM domU on storage driver domain



On Fri, Feb 24, 2017 at 10:13:53PM +0800, G.R. wrote:
> On Thu, Feb 23, 2017 at 8:44 PM, Roger Pau Monné <roger.pau@xxxxxxxxxx> wrote:
> >> libxl: debug: libxl_dm.c:2094:libxl__spawn_local_dm: Spawning device-model 
> >> /usr/local/lib/xen/bin/qemu-dm with arguments:
> >> libxl: debug: libxl_dm.c:2096:libxl__spawn_local_dm:   
> >> /usr/local/lib/xen/bin/qemu-dm
> >> libxl: debug: libxl_dm.c:2096:libxl__spawn_local_dm:   -d
> >> libxl: debug: libxl_dm.c:2096:libxl__spawn_local_dm:   92
> >> libxl: debug: libxl_dm.c:2096:libxl__spawn_local_dm:   -domain-name
> >> libxl: debug: libxl_dm.c:2096:libxl__spawn_local_dm:   ruibox-dm
> >> libxl: debug: libxl_dm.c:2096:libxl__spawn_local_dm:   -vnc
> >> libxl: debug: libxl_dm.c:2096:libxl__spawn_local_dm:   0.0.0.0:0
> >> libxl: debug: libxl_dm.c:2096:libxl__spawn_local_dm:   -vncunused
> >> libxl: debug: libxl_dm.c:2096:libxl__spawn_local_dm:   -M
> >> libxl: debug: libxl_dm.c:2096:libxl__spawn_local_dm:   xenpv
> >> libxl: debug: libxl_dm.c:2098:libxl__spawn_local_dm: Spawning device-model 
> >> /usr/local/lib/xen/bin/qemu-dm with additional environment:
> >> libxl: debug: libxl_dm.c:2100:libxl__spawn_local_dm:   
> >> XEN_QEMU_CONSOLE_LIMIT=1048576
> >> libxl: debug: libxl_event.c:636:libxl__ev_xswatch_register: watch 
> >> w=0x56365a684860 wpath=/local/domain/0/device-model/92/state token=3/2: 
> >> register slotnum=3
> >> libxl: debug: libxl_event.c:573:watchfd_callback: watch w=0x56365a684860 
> >> wpath=/local/domain/0/device-model/92/state token=3/2: event 
> >> epath=/local/domain/0/device-model/92/state
> >> libxl: debug: libxl_exec.c:398:spawn_watch_event: domain 92 device model: 
> >> spawn watch p=(null)
> >> libxl: debug: libxl_event.c:573:watchfd_callback: watch w=0x56365a684860 
> >> wpath=/local/domain/0/device-model/92/state token=3/2: event 
> >> epath=/local/domain/0/device-model/92/state
> >> libxl: debug: libxl_exec.c:398:spawn_watch_event: domain 92 device model: 
> >> spawn watch p=running
> >> libxl: debug: libxl_event.c:673:libxl__ev_xswatch_deregister: watch 
> >> w=0x56365a684860 wpath=/local/domain/0/device-model/92/state token=3/2: 
> >> deregister slotnum=3
> >> libxl: debug: libxl_exec.c:129:libxl_report_child_exitstatus: domain 92 
> >> device model (dying as expected) [733] died due to fatal signal Killed
> >
> > This seems suspicious, you shouldn't need a device-model for the subdomain
> > itself, can you please paste your domain config file?
> 
> So glad to see your comment!.
> I can debug with your instruction, so no need to reproduce from your
> side unless absolutely necessary.
> 
> The domU config file could be found in previous mails in this thread.
> But reattach anyway:

Hm, AFAICT the problem seem to be that there's a device model launched to serve
the stubdomain, and that's completely wrong. The stubdomain shouldn't require a
device model at all IMHO.

> There is yet other question I would like to see your comment, just to
> rule out the possibility that the driver domain is the bad guy:
> > Besides, the log attached above, I also find one old message from you:
> > https://lists.freebsd.org/pipermail/freebsd-xen/2016-June/002731.html
> > While you emphasized that's for dom0 support, I'm just wondering if,
> > by any tiny chance, it would affect FreeBSD as storage driver domain?
> > I'm on XEN 4.8 && FreeNAS 9.10 (FreeBSD 10.3 based) now.

That's only relevant to FreeBSD >= 11, 10.3 should be fine without needing
anything else.

> The background is that, as I mentioned in the very beginning of this
> thread, I'm also trying to use local qemu device model + driver domain
> by NFS mounting the remote disk image.
> The domU appears to go through the BIOS boot into windows while get
> stuck in the boot screen.
> According to Paul the win-pv-driver owner, the debug log looks just
> fine and it's probably that the back-end that is not working properly.
> Email thread could be found here:
> https://lists.xen.org/archives/html/win-pv-devel/2017-02/msg00027.html

Is the NFS share on a guest on the same host? I remember issues when trying to
do NFS from a guest and mounting the share on the Dom0.

Can you please try the following patch below and post the log of xl -vvv again:

---8<---
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 281058d..14014f4 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -2370,7 +2370,10 @@ int libxl__need_xenpv_qemu(libxl__gc *gc, 
libxl_domain_config *d_config)
         goto out;
     }
 
+    LOGD(DEBUG, domid, "Testing if domain needs DM");
+
     if (d_config->num_vfbs > 0) {
+        LOGD(DEBUG, domid, "DM needed for vfbs");
         ret = 1;
         goto out;
     }
@@ -2387,6 +2390,7 @@ int libxl__need_xenpv_qemu(libxl__gc *gc, 
libxl_domain_config *d_config)
         for (i = 0; i < num; i++) {
             if (dt->dm_needed(libxl__device_type_get_elem(dt, d_config, i),
                               domid)) {
+                LOGD(DEBUG, domid, "DM needed for disk %d", i);
                 ret = 1;
                 goto out;
             }
@@ -2398,6 +2402,7 @@ int libxl__need_xenpv_qemu(libxl__gc *gc, 
libxl_domain_config *d_config)
             /* xenconsoled is limited to the first console only.
                Until this restriction is removed we must use qemu for
                secondary consoles which includes all channels. */
+            LOGD(DEBUG, domid, "DM needed for console %d", i);
             ret = 1;
             goto out;
         }


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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.