[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


 


Rackspace

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