[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 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!). > 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.. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |