Launching QEMU directly is not merely "tricky", but incredibly inefficient and ineffective once you need something that's beyond bare minimal.
E.g. here is a minimal QEMU command-line that gives you access to a serial console in the guest:
`qemu-system-x86_64 -display none -no-user-config -nodefaults -m 2048 -device virtio-scsi-pci,id=scsi -device virtio-serial-pci -serial stdio -drive file=/export/cirros.qcow2,format=qcow2,if=virtio`
Simple, yeah? Now here (it's too long to post in this comment) is a real world QEMU command-line (as launched by the libvirt[1]):
htttps://kashyapc.fedorapeople.org/Fedora-28-QEMU-command-line-by-libvirt.txt
Compare and contrast the number of devices that libvirt adds.
FWIW, I strongly recommend to use libvirt to launch your QEMU-based guests. It is far more effective, and more importantly, provides security infrastructure like running the QEMU process as an unprivileged user, protecting the QEMU process (and its associated disk iamges) via the SELinux-based sVirt mechanism, and so forth.
Check out these[2] slides (recording is online, too) on "Security in QEMU" from one of the QEMU maintainers, Stefan Hajnoczi, at last year's KVM Forum in Edinburgh.
[1] http://libvirt.org/
[2] https://vmsplice.net/~stefan/stefanha-kvm-forum-2018.pdf
E.g. here is a minimal QEMU command-line that gives you access to a serial console in the guest:
`qemu-system-x86_64 -display none -no-user-config -nodefaults -m 2048 -device virtio-scsi-pci,id=scsi -device virtio-serial-pci -serial stdio -drive file=/export/cirros.qcow2,format=qcow2,if=virtio`
Simple, yeah? Now here (it's too long to post in this comment) is a real world QEMU command-line (as launched by the libvirt[1]):
htttps://kashyapc.fedorapeople.org/Fedora-28-QEMU-command-line-by-libvirt.txt
Compare and contrast the number of devices that libvirt adds.
FWIW, I strongly recommend to use libvirt to launch your QEMU-based guests. It is far more effective, and more importantly, provides security infrastructure like running the QEMU process as an unprivileged user, protecting the QEMU process (and its associated disk iamges) via the SELinux-based sVirt mechanism, and so forth.
Check out these[2] slides (recording is online, too) on "Security in QEMU" from one of the QEMU maintainers, Stefan Hajnoczi, at last year's KVM Forum in Edinburgh.
[1] http://libvirt.org/
[2] https://vmsplice.net/~stefan/stefanha-kvm-forum-2018.pdf