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

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

On Thu, Mar 2, 2017 at 5:42 PM, Roger Pau Monné <roger.pau@xxxxxxxxxx> wrote:
> Oh, sorry, I didn't realize there was an attachment to that email. It looks
> like the stubdom is able to connect to all the frontends and backends (both 
> the
> disk and the nic are in state "4"), however the QEMU inside the stubdomain is
> not able to start. It should set:
> /local/domain/3/device-model/2/state = "running"
> And that's not happening. I suggest that you add some debug printf's to QEMU
> and rebuild the stubdomain in order to know why QEMU is not starting up
> properly.
> Roger.

I'm trying as you suggested, but still get confused.

The log I'm seeing is:
stubdom dbg=13
stubdom dbg=14
stubdom dbg=15, vm_running=1, paused=0
xen be: console-1: xen be: console-1: initialise() failed
initialise() failed

Which corresponds to the following debug log I added:
626     printf("stubdom dbg=13\n");
627     xenstore_record_dm_state("running");
629     printf("stubdom dbg=14\n");
630     qemu_set_fd_handler(xenstore_fd(), xenstore_process_event, NULL, NULL);
632     printf("stubdom dbg=15, vm_running=%d, paused=%d\n",
vm_running, xen_pause_requested);
633     while (1) {
634         while (!(vm_running && xen_pause_requested))
636             /* Wait up to 10 msec. */
637             main_loop_wait(10);
638 #else
639             /* Wait up to 1h. */
640             main_loop_wait(1000*60*60);
641 #endif
643             printf("stubdom dbg=16\n");

So the 'running' stage should have been reached, at least once.
But still, libxl complain about device-model timeout:
libxl: debug: libxl_event.c:636:libxl__ev_xswatch_register: watch
w=0x5597e5a36a18 wpath=/local/domain/13/device-model/12/state
token=3/4: register slotnum=3
libxl: debug: libxl_event.c:573:watchfd_callback: watch
w=0x5597e5a36a18 wpath=/local/domain/13/device-model/12/state
token=3/4: event epath=/local/domain/13/device-model/12/state
libxl: debug: libxl_aoutils.c:88:xswait_timeout_callback: Stubdom 13
for 12 startup: xswait timeout
libxl: debug: libxl_event.c:673:libxl__ev_xswatch_deregister: watch
w=0x5597e5a36a18 wpath=/local/domain/13/device-model/12/state
token=3/4: deregister slotnum=3
libxl: error: libxl_dm.c:1963:stubdom_xswait_cb: Stubdom 13 for 12
startup: startup timed out
libxl: debug: libxl_event.c:686:libxl__ev_xswatch_deregister: watch
w=0x5597e5a36a18: deregister unregistered
libxl: error: libxl_create.c:1504:domcreate_devmodel_started: device
model did not start: -9

***Is the timeout really waiting for 'running' state?***
***Is the 'running' state going to be consumed and need to be regenerated?***
***Is there any other event that libxl is watching for?***

BTW2, there are some time out error waiting for the disk from storage
driver domain to be removed upon destroy:
libxl: error: libxl.c:1647:devices_destroy_cb: libxl__devices_destroy
failed for 13
libxl: debug: libxl.c:1712:devices_destroy_cb: forked pid 12559 for
destroy of domain 13
libxl: debug: libxl_aoutils.c:88:xswait_timeout_callback: removal of
backend path: xswait timeout
libxl: debug: libxl_event.c:673:libxl__ev_xswatch_deregister: watch
w=0x5597e5a404d0 wpath=/local/domain/1/backend/vbd/12/51712 token=1/9:
deregister slotnum=1
libxl: error: libxl_device.c:1264:device_destroy_be_watch_cb: timed
out while waiting for /local/domain/1/backend/vbd/12/51712 to be
libxl: debug: libxl_event.c:686:libxl__ev_xswatch_deregister: watch
w=0x5597e5a404d0: deregister unregistered
libxl: error: libxl.c:1647:devices_destroy_cb: libxl__devices_destroy
failed for 12

Xen-users mailing list



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