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

["G.R." <firemeteor@xxxxxxxxxxxxxxxxxxxxx>]

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.

BTW, a side product of my typo shows how the system responses to a
non-existing disk image in the storage driver domain.
This time vbd is explicitly mentioned in the log while no 'Spawning
device-model...' log is found.
I think this suggests that the back-end in FreeNAS domU is at least
not entirely unresponsive.

libxl: debug: libxl_event.c:573:watchfd_callback: watch
w=0x55bbe3fc9270 wpath=/local/domain/1/backend/vbd/16/51712/state
token=3/0: event epath=/local/domain/1/backend/vbd/16/51712/state
libxl: debug: libxl_event.c:878:devstate_callback: backend
/local/domain/1/backend/vbd/16/51712/state wanted state 2 still
waiting state 1
libxl: debug: libxl_aoutils.c:88:xswait_timeout_callback: backend
/local/domain/1/backend/vbd/16/51712/state (hoping for state change to
2): xswait timeout (path=/local/domain/1/backend/vbd/16/51712/state)
libxl: debug: libxl_event.c:673:libxl__ev_xswatch_deregister: watch
w=0x55bbe3fc9270 wpath=/local/domain/1/backend/vbd/16/51712/state
token=3/0: deregister slotnum=3
libxl: debug: libxl_event.c:862:devstate_callback: backend
/local/domain/1/backend/vbd/16/51712/state wanted state 2  timed out
libxl: debug: libxl_event.c:686:libxl__ev_xswatch_deregister: watch
w=0x55bbe3fc9270: deregister unregistered
libxl: debug: libxl_device.c:1059:device_backend_callback: calling
device_backend_cleanup
libxl: debug: libxl_event.c:686:libxl__ev_xswatch_deregister: watch
w=0x55bbe3fc9270: deregister unregistered
libxl: error: libxl_device.c:1074:device_backend_callback: unable to
add device with path /local/domain/1/backend/vbd/16/51712
libxl: debug: libxl_event.c:686:libxl__ev_xswatch_deregister: watch
w=0x55bbe3fc9370: deregister unregistered
libxl: error: libxl_create.c:1255:domcreate_launch_dm: unable to add
disk devices

Thanks,
Rui

Attachment: exp2.log
Description: Text Data

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