search for: 37cfb3d4eb3d3a1c86b2

...h, I didn't have sgabios installed, and it complained it couldn't > find an event (qemu:overhead?). Right - it's very sensitive to the exact debug output. > Installed it and I got similar results to yours, the largest > overhead is BIOS: > https://gist.github.com/anonymous/37cfb3d4eb3d3a1c86b2 Your qemu overhead is lower. That could be because of: https://bugzilla.redhat.com/show_bug.cgi?id=1319483 Interestingly your total time is at least double mine. Either your hardware is slower or there's something else going on. > Thought to try booting a Xen PV domain for comparison...

...SGABIOS (it contains a useless ¼s sleep waiting for a > keypress ... ffs!) Ah, I didn't have sgabios installed, and it complained it couldn't find an event (qemu:overhead?). Installed it and I got similar results to yours, the largest overhead is BIOS: https://gist.github.com/anonymous/37cfb3d4eb3d3a1c86b2 Thought to try booting a Xen PV domain for comparison, but AFAICT libguestfs doesn't support LIBGUESTFS_BACKEND=libvirt:xen:/// >, and the other ⅔rds is something else in SeaBIOS. > Simply removing SGABIOS improves boot times to below 2s, but at a cost > that we cannot see any messag...

v1 was here: https://www.redhat.com/archives/libguestfs/2016-March/thread.html#00157 Not running the 'hwclock' command reduces boot times considerably. However I'm not sure if it is safe. See the question I posted on qemu-devel: http://thread.gmane.org/gmane.comp.emulators.qemu/402194 At the moment, about 50% of the time is consumed by SeaBIOS. Of this, about ⅓rd is SGABIOS