[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] libxl: cannot start guest
On Mon, 2012-05-21 at 14:10 +0100, Christoph Egger wrote: > On 05/21/12 14:15, Ian Campbell wrote: > > > On Mon, 2012-05-21 at 11:26 +0100, Christoph Egger wrote: > >> On 05/18/12 17:58, Ian Campbell wrote: > >> > >>> > >>>> In libxl__build_post() I check the return value > >>>> of libxl__sched_set_params(). > >>> > >>> The mesages about scheduler params are a known and benign issue. > >>> > >>>> Now trying to start a guest results in this failure: > >>>> > >>>> xc: info: VIRTUAL MEMORY ARRANGEMENT: > >>>> Loader: 0000000000100000->000000000019bd04 > >>>> TOTAL: 0000000000000000->00000000ff800000 > >>>> ENTRY ADDRESS: 0000000000100000 > >>>> xc: info: PHYSICAL MEMORY ALLOCATION: > >>>> 4KB PAGES: 0x0000000000000200 > >>>> 2MB PAGES: 0x00000000000003fb > >>>> 1GB PAGES: 0x0000000000000002 > >>>> libxl: error: libxl.c:3211:libxl_sched_credit_domain_set: Cpu weight out > >>>> of range, valid values are within range from 1 to 65535 > >>>> libxl: error: libxl_create.c:694:domcreate_bootloader_done: cannot > >>>> (re-)build domain: -6 > >>>> libxl: error: libxl_dm.c:1104:libxl__destroy_device_model: Couldn't find > >>>> device model's pid: No such file or directory > >>> > >>> Is your device model dying for some reason? Anything > >>> in /var/log/xen/*guest*.log about it? > >> > >> > >> The guest logfile doesn't exist. > > > > Sorry, I meant guest as in $GUEST_NAME rather than literally "guest" (I > > was totally non-obvious about that, sorry!). > > > I understood it that way. The guest logfile doesn't exist. > > > > >> Does that mean the errors happens before device model has been started at > >> all? > > > > I think/hope if that were the case you would get messages about failure > > to exec etc rather than timeouts. > > > >>> > >>> You could try "xl -vvv cr ..." too, not sure what it will say. > >> > >> > >> libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk > >> vdev=hda spec.backend=unknown > >> libxl: debug: libxl_device.c:219:libxl__device_disk_set_backend: Disk > >> vdev=hda, using backend phy > >> xc: detail: elf_parse_binary: phdr: paddr=0x100000 memsz=0x9bd04 > >> xc: detail: elf_parse_binary: memory: 0x100000 -> 0x19bd04 > >> xc: info: VIRTUAL MEMORY ARRANGEMENT: > >> Loader: 0000000000100000->000000000019bd04 > >> TOTAL: 0000000000000000->00000000ff800000 > >> ENTRY ADDRESS: 0000000000100000 > >> xc: info: PHYSICAL MEMORY ALLOCATION: > >> 4KB PAGES: 0x0000000000000200 > >> 2MB PAGES: 0x00000000000003fb > >> 1GB PAGES: 0x0000000000000002 > > > > No messages about "xs transaction failed: Bad file descriptor" any more? > > > >> xc: detail: elf_load_binary: phdr 0 at 0x0x7f7ff7f42000 -> 0x0x7f7ff7fd4b74 > >> libxl: error: libxl.c:3211:libxl_sched_credit_domain_set: Cpu weight out > >> of range, valid values are within range from 1 to 65535 > >> libxl: error: libxl_create.c:694:domcreate_bootloader_done: cannot > >> (re-)build domain: -6 > >> libxl: error: libxl_dm.c:1104:libxl__destroy_device_model: Couldn't find > >> device model's pid: No such file or directory > >> libxl: error: libxl.c:1162:libxl_domain_destroy: > >> libxl__destroy_device_model failed for 2 > > > > Hrm, actually, the device model stuff might be a red-herring -- that's > > trying to tear down the device model on failure and it is entirely > > reasonable for the device model to not be running if we didn't get as > > far as starting it... > > > > The interesting message is just: > >> libxl: error: libxl_create.c:694:domcreate_bootloader_done: cannot > >> (re-)build domain: -6 > > > > Which is unhelpfully just a general failure from libxl__domain_build. > > > > It seems that we have a non-logging failure path in there somewhere. I'm > > afraid that the easieist way to fix this is probably just to dive into > > libxl__domain_build and add prints on the various error cases of sub > > functions, then recurse as you identify which one is failing etc.. > > I did that: > > Parsing config from /root/hvm-guest/netbsd_64b.conf > libxl: debug: libxl_device.c:183:libxl__device_disk_set_backend: Disk > vdev=hda spec.backend=unknown > libxl: debug: libxl_device.c:219:libxl__device_disk_set_backend: Disk > vdev=hda, using backend phy > xc: detail: elf_parse_binary: phdr: paddr=0x100000 memsz=0x9bd04 > xc: detail: elf_parse_binary: memory: 0x100000 -> 0x19bd04 > xc: info: VIRTUAL MEMORY ARRANGEMENT: > Loader: 0000000000100000->000000000019bd04 > TOTAL: 0000000000000000->00000000ff800000 > ENTRY ADDRESS: 0000000000100000 > xc: info: PHYSICAL MEMORY ALLOCATION: > 4KB PAGES: 0x0000000000000200 > 2MB PAGES: 0x00000000000003fb > 1GB PAGES: 0x0000000000000002 > xc: detail: elf_load_binary: phdr 0 at 0x0x7f7ff7f42000 -> 0x0x7f7ff7fd4b74 > libxl: error: libxl.c:3213:libxl_sched_credit_domain_set: Cpu weight out > of range, valid values are within range from 1 to 65535 > libxl: error: libxl_dom.c:74:libxl__sched_set_params: > libxl_sched_credit_domain_set failed -6 > libxl: error: libxl_dom.c:192:libxl__build_post: libxl__sched_set_params > failed -6 > libxl: error: libxl_create.c:322:libxl__domain_build: libxl__build_post > failed: -6 > libxl: error: libxl_create.c:709:domcreate_bootloader_done: cannot > (re-)build domain: -6 > libxl: error: libxl_dm.c:1104:libxl__destroy_device_model: Couldn't find > device model's pid: No such file or directory > libxl: error: libxl.c:1162:libxl_domain_destroy: > libxl__destroy_device_model failed for 6 > xc: debug: hypercall buffer: total allocations:1264 total releases:1264 > xc: debug: hypercall buffer: current allocations:0 maximum allocations:2 > xc: debug: hypercall buffer: cache current size:2 > xc: debug: hypercall buffer: cache hits:1261 misses:2 toobig:1 > libxl: error: libxl.c:155:libxl_ctx_free: libxl_ctx_free: call > xs_daemon_close > > > So it is indeed that ERROR_INVAL from that 'benign' error In my version of libxl libxl__build_post doesn't even look at the return value of libxl__sched_set_params. .... libxl__sched_set_params (gc, domid, &(info->sched_params)); .... the only other exit path from that function is: dom_path = libxl__xs_get_dompath(gc, domid); if (!dom_path) { return ERROR_FAIL; } which is consistent with the original errors you had (but if ERROR_FAIL, not ERROR_INVAL). This doesn't really help me figure out what is going on though :-/ Ian. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |