[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |