Hello, I recently swapped some components, and rebuilt my system. Changes to the configuration: - Wheezy Beta 1 > Wheezy Beta 2 - Kernel 3.4.9 > Kernel 3.4.11 I have tested the new Xen 4.2 stable, and Xen unstable revision 25777, both are giving me the same error so I do not believe it is related to a change in Xen. The first attempt to pass a PCI device after booting the system gives me these messages (on "xl create"): libxl: error: libxl_dom.c:557:libxl__build_hvm: hvm building failed libxl: error: libxl_create.c:901:domcreate_rebuild_done: cannot (re-)build domain: -3 libxl: error: libxl_dm.c:1239:libxl__destroy_device_model: could not find device-model''s pid for dom 1 libxl: error: libxl.c:1427:libxl__destroy_domid: libxl__destroy_device_model failed for 1 The baffling part is that all subsequent attempts are successful. So if I rerun "xl create" it works, and I can do it as many times as I want. If I reboot then I get the error again. Any ideas what the cause could be? Thanks, ~Casey DeLorme _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users
On Fri, 2012-09-21 at 18:49 +0100, Casey DeLorme wrote:> The first attempt to pass a PCI device after booting the system gives > me these messages (on "xl create"): > > > libxl: error: libxl_dom.c:557:libxl__build_hvm: hvm building failed > libxl: error: libxl_create.c:901:domcreate_rebuild_done: cannot (re-)build domain: -3 > libxl: error: libxl_dm.c:1239:libxl__destroy_device_model: could not find device-model''s pid for dom 1 > libxl: error: libxl.c:1427:libxl__destroy_domid: libxl__destroy_device_model failed for 1xl -vvv create might tell you a bit more but it seems likely that the interesting logs will be in /var/log/xen/qemu-dm-<name>.log or in the Xen dmesg. Ian.
That''s the odd part, absolutely no logs are generated when it errors out. Also, if I run the same xl create command immediately after, it works just fine. On Mon, Sep 24, 2012 at 4:34 AM, Ian Campbell <Ian.Campbell@citrix.com>wrote:> On Fri, 2012-09-21 at 18:49 +0100, Casey DeLorme wrote: > > The first attempt to pass a PCI device after booting the system gives > > me these messages (on "xl create"): > > > > > > libxl: error: libxl_dom.c:557:libxl__build_hvm: hvm building failed > > libxl: error: libxl_create.c:901:domcreate_rebuild_done: cannot > (re-)build domain: -3 > > libxl: error: libxl_dm.c:1239:libxl__destroy_device_model: could not > find device-model''s pid for dom 1 > > libxl: error: libxl.c:1427:libxl__destroy_domid: > libxl__destroy_device_model failed for 1 > > xl -vvv create might tell you a bit more but it seems likely that the > interesting logs will be in /var/log/xen/qemu-dm-<name>.log or in the > Xen dmesg. > > Ian. > > >_______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users
Can you not top post please, it makes the flow of a conversation hard to follow. On Mon, 2012-09-24 at 09:56 +0100, Casey DeLorme wrote:> That''s the odd part, absolutely no logs are generated when it errors > out.Are you sure you have run "xl -vvv create", because AFAICT there is no way that "hvm building failed" can be the first message printed in verbose mode. Ian.
Please can you keep the ML in the loop. I have added it back this time. On Mon, 2012-09-24 at 10:23 +0100, Casey DeLorme wrote:> Sorry it was not intentional, gmail automatically positions my > response above the last message.So please move the cursor before you start typing. This will also give you the opportunity to trim your quotes to the appropriate amount of context.> First attempt after rebooting the platform running "xl -vvv > create /etc/xen/windows.cfg" yields: > > cdelorme@xen:~$ xl -vvv create /etc/xen/windows.cfg > Parsing config from /etc/xen/windows.cfg > libxl: debug: libxl_create.c:1173:do_domain_create: ao 0x1480890: create: how=(nil) callback=(nil) poller=0x1480b80 > libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend: Disk vdev=hda spec.backend=unknown > libxl: debug: libxl_device.c:265:libxl__device_disk_set_backend: Disk vdev=hda, using backend phy > libxl: debug: libxl_create.c:677:initiate_domain_create: running bootloader > libxl: debug: libxl_bootloader.c:321:libxl__bootloader_run: not a PV domain, skipping bootloader > libxl: debug: libxl_event.c:561:libxl__ev_xswatch_deregister: watch w=0x1481bd0: deregister unregistered > libxl: notice: libxl_numa.c:451:libxl__get_numa_candidate: NUMA placement failed, performance might be affected > xc: detail: elf_parse_binary: phdr: paddr=0x100000 memsz=0x9df08 > xc: detail: elf_parse_binary: memory: 0x100000 -> 0x19df08 > xc: info: VIRTUAL MEMORY ARRANGEMENT: > Loader: 0000000000100000->000000000019df08 > TOTAL: 0000000000000000->00000001ff000000 > ENTRY ADDRESS: 0000000000100000 > xc: detail: Failed allocation for dom 1: 2048 extents of order 0 > xc: error: Could not allocate memory for HVM guest. (16 = Device or resource busy): Internal errorHere is your actual error message. I have two guesses as to what is happening here. First is that, for some reason, dom0 is too slow to balloon down and xl has failed to notice this somehow. By the time you run your second domain domain 0 has caught up. The other option is that perhaps xl is underestimating the RAM required to start the domain (perhaps passthrough adds some additional memory overhead which it doesn''t correctly account for) but by making room for this first domain it inadvertently adds enough slack to the system that a starting the second time succeeds. If this is the case then there is a second order bug here which is that xl didn''t balloon backup after the initial domain create failed. Either way this sounds like a bug in xl''s autoballooning code, it would be useful to report as such on xen-devel. One obvious solution/workaround would be to use the dom0_mem option and disable auto ballooning. Ian.
Sorry, thought I hit reply all, this time making sure I do it right. I have two guesses as to what is happening here.> > First is that, for some reason, dom0 is too slow to balloon down and xl > has failed to notice this somehow. By the time you run your second > domain domain 0 has caught up. > > The other option is that perhaps xl is underestimating the RAM required > to start the domain (perhaps passthrough adds some additional memory > overhead which it doesn''t correctly account for) but by making room for > this first domain it inadvertently adds enough slack to the system that > a starting the second time succeeds. If this is the case then there is a > second order bug here which is that xl didn''t balloon backup after the > initial domain create failed. > >You are probably right, I changed some equipment and went from 6GB of RAM and 3 devices to 8GB of RAM and 4 devices. I tried dropping it to 4GB but that didn''t seem to solve the problem either. Either way this sounds like a bug in xl''s autoballooning code, it would> be useful to report as such on xen-devel. > >Should I forward this response to the xen-devel list, or just create a brand new message?> One obvious solution/workaround would be to use the dom0_mem option and > disable auto ballooning. > >I will give this a try after work today and report back. Thanks very much for your help and advice on this. ~Casey _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users
Added dom0_mem=4096MB to my grub configuration, rebooted, and all is well. I am no longer getting any errors. Ian, thank you very much for the suggestion, even though the error message claimed it was memory I would never have assumed a problem with the ballooning. I will be sure to draft up something to send to the xen-devel list. I use Dom0 for development, when I am not using the HVM for multimedia. So I have left ballooning on, so if more RAM is needed it can access it. ~Casey _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users