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

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



On Sun, Feb 26, 2017 at 09:49:31PM +0800, G.R. wrote:
> On Sat, Feb 25, 2017 at 12:07 AM, Roger Pau Monné <roger.pau@xxxxxxxxxx> 
> wrote:
> > 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
> > 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.
> I don't think I agree with your judgment.
> With stubdom config, I could see a new domain launched along with the
> domU in question:
> Name                                        ID   Mem VCPUs    State    Time(s)
> Domain-0                                     0  1024     6     r-----     
> 137.0
> nas                                          1  7936     2     -b----     
> 444.0
> ruibox                                       6  2047     1     --p---       
> 0.0
> ruibox-dm                                    7    32     1     -b----       
> 0.0

Yes, that's expected, it's the stubdomain (the domain running the device
model).

> The 'ruibox-dm' name is referenced in the qemu-dm parameter log.
> I think this comes from spawn_stub_launch_dm() which calls
> libxl__spawn_local_dm() and prints out the log in question.

If it calls local_dm, it means it's launching a local device model (apart from
the stubdomain) which AFAICT it's wrong. The stubdomain itself shouldn't
require a device model on Dom0 in order to run (or at least that's my
recollection).

> Also the debug patch you created are not being triggered at all.
> The libxl__need_xenpv_qemu() function you touched are called in two 
> situations:
> 1. in domcreate_launch_dm() for PV path, which is not applicable here
> since it's HVM.

The stubdomain (ruibox-dm) it's a PV domain, so it should go that route
(libxl__need_xenpv_qemu).

Can you please paste the log with the patch applied? (and xl -vvv ...)

Roger.

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

 


Rackspace

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