Compatibility
There should be no issues. QEMU doesn't look any different functionally from regular hardware to the guest system, and LXC does nothing that requires special behavior from the hardware that QEMU doesn't emulate.
But...
You probably don't want to do this, not only because it will hurt performance, but it will also significantly complicate management. You should probably re-evaluate why you think you need VM's under the containers (or, better yet, if you are already using containers for part of your infrastructure, why you need to use VM's instead for the rest of it). Unless you really care about live migration or improved isolation of workloads beyond what containers provide, you're probably better off just adapting the rest of your infrastructure to use containers because they use fewer resources. The only exception to this is systems which provide services that are accessible to the outside world, which should never be on a shared host unless they're in a VM (because crashing a container will quite often crash the host), and even then should generally not be on a shared host with internal services.
OK, but I really want to do this anyway.
In that case, work on adapting your software to use VM's instead of containers. Realistically, it shouldn't be too hard to adapt. It's actually pretty easy to set QEMU up to directly boot a Linux kernel (and therefore bypass the need for a bootloader, and with it the need for a partition table), and once you can do that it's easy to extract that container base image into a filesystem image which you can then use directly as a disk (this would still be a bit lower performance than the containers, but nowhere near as bad as running the containers inside the VM's).
