search for: virtlib

...FW is stealing the DHCP response away before iPXE gets it? I haven't thought of this possibility. Or am I misunderstanding you? Since I'm having a hard time getting the FW to grok syslinux, I find it surprising it gets this far. And I also have the same problem on my virtual qemu/kvm/virtlib/ovmf setup where iPXE *IS* the firmware. > it looks like iPXE might still have the chainloading issue Which issue are you referring to?

...ng indefinitely? >> >> BTW: is this all the debug messages you have? Because in there, the last line is how libvirtd starts qemu-system-x86_64 in order to fetch its capabilities. I'd expect libvirt setting qmp_capabilities on the monitor at least. >> >> Michal > > Virtlib logs end in the way you see, only when i kill the qemu process > then it starts logging and it is possible to connect remotely with > virsh. I see. There's nothing suspicious in the logs. The fact that libvirt waits for qemu suggests that qemu did not go daemon. I mean, we pass -daemoniz...

On 04/30/2017 07:12 PM, Stefano Ricci wrote: > > The version used for backtrace is 3.2.0, now I have also tried the > current downloaded with git but the problem is always present. > This is the current version log file, set as shown on the DebugLogs page: > > https://drive.google.com/open?id=0By9lwQyveHENdEt4aEtZcUV3ZEU Couple of my findings: 2017-04-30 16:19:34.894+0000:

...E is trigerring a new PXE sequence with a different arch but the one that finally loads the new NBP is really the FW. >>> Since I'm having a hard time getting the FW to grok syslinux, I find it surprising it gets this far. And I also have the same problem on my virtual qemu/kvm/virtlib/ovmf setup where iPXE *IS* the firmware. <<< I call FW to the EFI executive that comes within your PC. iPXE is an NBP. Your firmware should load syslinux.efi w/o much trouble, if you do not have multi-NIC hardware. or if you use the last patched syslinux >>> > it looks lik...

...r some time. Or does it hang indefinitely? > > BTW: is this all the debug messages you have? Because in there, the last line is how libvirtd starts qemu-system-x86_64 in order to fetch its capabilities. I'd expect libvirt setting qmp_capabilities on the monitor at least. > > Michal Virtlib logs end in the way you see, only when i kill the qemu process then it starts logging and it is possible to connect remotely with virsh. Until the qemu process is active you can not use libvirt. In the following libvirt log file find all that happens when killing the qemu process, after the line 20...

...t;> >>> BTW: is this all the debug messages you have? Because in there, the last line is how libvirtd starts qemu-system-x86_64 in order to fetch its capabilities. I'd expect libvirt setting qmp_capabilities on the monitor at least. >>> >>> Michal >> >> Virtlib logs end in the way you see, only when i kill the qemu process >> then it starts logging and it is possible to connect remotely with >> virsh. > > I see. There's nothing suspicious in the logs. The fact that libvirt > waits for qemu suggests that qemu did not go daemon. I m...

On 31-07-15 14:25, Patrick Masotta wrote: > ""exponential-like decay of IO rate"" could you please post a link on > your comments on this? Sure, see the thread starting at: http://www.syslinux.org/archives/2015-June/023621.html And Gene's confirmation at: http://www.syslinux.org/archives/2015-June/023629.html > OK I got lost. > are you saying you finally

...e HP ROM FW can only do tftp, so it must be iPXE that's downloading and running syslinux.efi. >>>> > Since I'm having a hard time getting the FW to grok syslinux, I find it > surprising it gets this far. And I also have the same problem on my > virtual qemu/kvm/virtlib/ovmf setup where iPXE *IS* the firmware. > <<< > I call FW to the EFI executive that comes within your PC. > iPXE is an NBP. > Your firmware should load syslinux.efi w/o much trouble, > if you do not have multi-NIC hardware. or if you use the last > patched syslinux I us...