Совместимость
Там не должно быть никаких проблем. QEMU функционально не отличается от обычного оборудования для гостевой системы, и LXC не делает ничего, требующего особого поведения от оборудования, которое QEMU не эмулирует.
Но...
Вы, вероятно, не хотите делать это не только потому, что это ухудшит производительность, но и значительно усложнит управление. Вам, вероятно, следует пересмотреть, почему вы считаете, что вам нужны виртуальные машины под контейнерами (или, что еще лучше, если вы уже используете контейнеры для части своей инфраструктуры, почему вы должны использовать виртуальные машины вместо остальных). Если вы действительнозаботясь о динамической миграции или улучшенной изоляции рабочих нагрузок от того, что предоставляют контейнеры, вам, вероятно, лучше просто адаптировать остальную часть своей инфраструктуры для использования контейнеров, поскольку они используют меньше ресурсов. Единственное исключение из этого - системы, которые предоставляют сервисы, доступные внешнему миру, которые никогда не должны находиться на общем хосте, если они не находятся в виртуальной машине (потому что сбой контейнера довольно часто приводит к краху хоста), и даже тогда следует как правило, не быть на общем хосте с внутренними службами.
Хорошо, но я действительно хочу сделать это в любом случае.
В этом случае работайте над адаптацией вашего программного обеспечения для использования виртуальных машин вместо контейнеров. Реально, это не должно быть слишком сложно для адаптации. На самом деле довольно просто настроить QEMU для непосредственной загрузки ядра Linux (и, следовательно, обойти необходимость в загрузчике, а вместе с ним и необходимость в таблице разделов), и, как только вы сможете это сделать, легко извлечь этот базовый образ контейнера в образ файловой системы, который вы затем можете использовать непосредственно в качестве диска (это все равно будет немного ниже производительности, чем контейнеры, но нигде не так плохо, как запуск контейнеров внутри виртуальных машин).