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

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

On Tue, Feb 28, 2017 at 09:54:05PM +0800, G.R. wrote:
> On Tue, Feb 28, 2017 at 1:37 AM, Roger Pau Monné <roger.pau@xxxxxxxxxx> wrote:
> > On Mon, Feb 27, 2017 at 10:13:15PM +0800, G.R. wrote:
> >> On Mon, Feb 27, 2017 at 5:47 PM, Roger Pau Monné <roger.pau@xxxxxxxxxx> 
> >> wrote:
> >> >
> >> > Can you please paste the log with the patch applied? (and xl -vvv ...)
> >> >
> >> Thank you for clarifying my misunderstandings.
> >> Please find the log in the attachment.
> >> To be honest, I wasn't able to find any fundamental difference.
> >> I even suspect if I applied the patch correctly. But I think its
> >> correctly patched:
> >
> > Yes, it's correctly patched, it's just not using the function that I've
> > patched. Stupid question, but does the same exact config file work if you 
> > move
> > the virtual disk to Dom0? (but still using a stubdomain, and not changing 
> > any
> > other options).
> I'll not be able to perform the exact experiment as you suggest since
> my dom0 only has access to a usb drive with 2GB partition...
> What I managed to do is to use a minimal liveCD as disk image (I also
> changed the domain name, which shouldn't be relevant).
> 
> The stubdomain config works this time. Comparing the -vvv log, I can
> also see the 'Spawning device-model ...' log.
> The only difference is that, for the failing run, it shows:
>   libxl: debug: libxl_event.c:636:libxl__ev_xswatch_register: watch
> w=0x5573d7180a18 wpath=/local/domain/9/device-model/8/state token=3/4:
> register slotnum=3
>   libxl: debug: libxl_event.c:573:watchfd_callback: watch
> w=0x5573d7180a18 wpath=/local/domain/9/device-model/8/state token=3/4:
> event epath=/local/domain/9/device-model/8/state
> >>>  libxl: debug: libxl_aoutils.c:88:xswait_timeout_callback: Stubdom 9 for 
> >>> 8 startup: xswait timeout (path=/local/domain/9/device-model/8/state)
>   libxl: debug: libxl_event.c:673:libxl__ev_xswatch_deregister: watch
> w=0x5573d7180a18 wpath=/local/domain/9/device-model/8/state token=3/4:
> deregister slotnum=3
>   libxl: error: libxl_dm.c:1963:stubdom_xswait_cb: Stubdom 9 for 8
> startup: startup timed out
>   libxl: debug: libxl_event.c:686:libxl__ev_xswatch_deregister: watch
> w=0x5573d7180a18: deregister unregistered
>   libxl: error: libxl_create.c:1504:domcreate_devmodel_started: device
> model did not start: -9
> 
> While for the working run, it shows:
> libxl: debug: libxl_event.c:636:libxl__ev_xswatch_register: watch
> w=0x55f894156668 wpath=/local/domain/20/device-model/19/state
> token=3/4: register slotnum=3
> libxl: debug: libxl_event.c:573:watchfd_callback: watch
> w=0x55f894156668 wpath=/local/domain/20/device-model/19/state
> token=3/4: event epath=/local/domain/20/device-model/19/state
> >>>libxl: debug: libxl_event.c:573:watchfd_callback: watch w=0x55f894156668 
> >>>wpath=/local/domain/20/device-model/19/state token=3/4: event 
> >>>epath=/local/domain/20/device-model/19/state
> libxl: debug: libxl_event.c:673:libxl__ev_xswatch_deregister: watch
> w=0x55f894156668 wpath=/local/domain/20/device-model/19/state
> token=3/4: deregister slotnum=3
> libxl: debug: libxl_event.c:636:libxl__ev_xswatch_register: watch
> w=0x55f894163c50 wpath=/local/domain/0/backend/vif/19/0/state
> token=3/5: register slotnum=3
> libxl: debug: libxl_event.c:573:watchfd_callback: watch
> w=0x55f894163c50 wpath=/local/domain/0/backend/vif/19/0/state
> token=3/5: event epath=/local/domain/0/backend/vif/19/0/state
> libxl: debug: libxl_event.c:878:devstate_callback: backend
> /local/domain/0/backend/vif/19/0/state wanted state 2 still waiting
> state 1
> libxl: debug: libxl_event.c:573:watchfd_callback: watch
> w=0x55f894163c50 wpath=/local/domain/0/backend/vif/19/0/state
> token=3/5: event epath=/local/domain/0/backend/vif/19/0/state
> libxl: debug: libxl_event.c:874:devstate_callback: backend
> /local/domain/0/backend/vif/19/0/state wanted state 2 ok
> 
> It's not clear to me what the time-outed watch is waiting for.
> While the disk back-end is highly suspicious, the context in the
> passing log looks more vif related.

Neither to me, it seems like the stubdomain doesn't start correctly, but the
stubdom log doesn't give any clues about what might cause it (or at least I'm
not able to identify them). Can you please apply the following patch, try to
create the domain (this time using the stubdom), and after 30s do `xenstore-ls
-fp` in the Dom0 and paste the results here?

This way I will know if the frontends in the stubdom have attached correctly.

Roger.

---8<---
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 7722665..4d4d18f 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -95,7 +95,7 @@
 #define LIBXL_DEVICE_MODEL_START_TIMEOUT 60
 #define LIBXL_DEVICE_MODEL_SAVE_FILE XEN_LIB_DIR "/qemu-save" /* .$domid */
 #define LIBXL_DEVICE_MODEL_RESTORE_FILE XEN_LIB_DIR "/qemu-resume" /* .$domid 
*/
-#define LIBXL_STUBDOM_START_TIMEOUT 30
+#define LIBXL_STUBDOM_START_TIMEOUT 120
 #define LIBXL_QEMU_BODGE_TIMEOUT 2
 #define LIBXL_XENCONSOLE_LIMIT 1048576
 #define LIBXL_XENCONSOLE_PROTOCOL "vt100"


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