Re: libxl: cannot start guest

[Christoph Egger <Christoph.Egger@amd.com>]

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.

Christoph


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632