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

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

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:

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.

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


> Roger.

Attachment: ruibox.cfg
Description: Binary data

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