What’s your goal? What do you think you’ll gain by doing it in Docker?
This seems unusual to me, because usually you want to run things in Docker so that they’re isolated from the host, but anything you run inside QEMU is already even more isolated, and isolating the emulator itself doesn’t seem especially valuable. For things like networking you need to contend with both the things Docker does and the things QEMU needs to do (so if you were running an emulated TCP service, you’d both need to map it from the QEMU virtual host and also publish the port from Docker). As a general rule, fewer layers doing the same thing is probably better.
It’s pretty trivial to find a prebuilt qemu image, but note that this only includes the emulator itself and not the VM image you’d want to run on top of it. Docker would consider those “data”, and you’d distribute them separately and attach them to the container at
docker run time. The tianon/qemu image looks roughly like what I’d expect. Note the
--device /dev/kmem: the container has unrestricted access to all host memory, which in effect means it’s running as root on the host.