Anthony Liguori <anth...@codemonkey.ws> writes: > On 01/18/2011 02:16 PM, Markus Armbruster wrote: >> The problem: you want to do serious scalability testing (1000s of VMs) >> of your management stack. If each guest eats up a few 100MiB and >> competes for CPU, that requires a serious host machine. Which you don't >> have. You also don't want to modify the management stack at all, if you >> can help it. >> >> The solution: a perfectly normal-looking QEMU that uses minimal >> resources. Ability to execute any guest code is strictly optional ;) >> >> New option -fake-machine creates a fake machine incapable of running >> guest code. Completely compiled out by default, enable with configure >> --enable-fake-machine. >> >> With -fake-machine, CPU use is negligible, and memory use is rather >> modest. >> >> Non-fake VM running F-14 live, right after boot: >> UID PID PPID C SZ RSS PSR STIME TTY TIME CMD >> armbru 15707 2558 53 191837 414388 1 21:05 pts/3 00:00:29 [...] >> >> Same VM -fake-machine, after similar time elapsed: >> UID PID PPID C SZ RSS PSR STIME TTY TIME CMD >> armbru 15742 2558 0 85129 9412 0 21:07 pts/3 00:00:00 [...] >> >> We're using a very similar patch for RHEL scalability testing. >> > > Interesting, but: > > 9432 anthony 20 0 153m 14m 5384 S 0 0.2 0:00.22 > qemu-system-x86 > > That's qemu-system-x86 -m 4
Sure you ran qemu-system-x86 -fake-machine? > In terms of memory overhead, the largest source is not really going to > be addressed by -fake-machine (l1_phys_map and phys_ram_dirty). git-grep phys_ram_dirty finds nothing. > I don't really understand the point of not creating a VCPU with KVM. > Is there some type of overhead in doing that? I briefly looked at both main loops, TCG's was the first one I happened to crack, and I didn't feel like doing both then. If the general approach is okay, I'll gladly investigate how to do it with KVM.
