No, that's not what libvirt does. libvirt abstracts handling of tools like Qemu, or LXC. No lowlevel stuff.
When people talk about libvirt, they usually mean the libvirt daemon that manages VMs or containers using other programs and accepts XML machine descriptions as input.
The actual "libvirt" library is simply a front end library for talking to the daemon and is used internally by tools like virsh (CLI) or virtman (GUI tool).
Some ~7 years ago I used the libvirt library for a small in-house tool. It has the possibly shittiest API ever designed. No abstraction whatsoever, just a couple C functions that accept XML strings as input and possibly return XML responses from the daemon.
However these days when just about everything is a service accessed by shuffling poorly documented and type-unsafe JSON documents over the network, maybe libvirt was just ahead of its time ... [Libvirt XML is incredibly well documented, probably in some ways over documented.]
(To be fair, if you're stuck for ideas for making something nastier, wrapping it in XML isn't a crazy starting point.)
Used libvirt for LXC, before "Docker" was the new kid on the block. Once we got it working it was great... but libvirt itself, ugh. There were some rubygems that abstracted some of the pain, that helped. Still the ugliness would poke through.
This was my experience as well. The only time I get near libvirt anymore is to read source; because sometimes it's the best documentation for a qemu feature.
I do like here that the author here went beyond minimal hello world and also showed how to boot linux
I've shared that with a lot of people, because it's a great introduction to stepping through the abstraction of QEMU (or libvirt or whatever) and seeing what KVM can do. There's some good articles that start from VMx on up, which are fun too, but much more involved than KVM.
In general, this is a kind of technical content I'd like to see more of: here's a lower-level API, what can I do with it?
Similarly, it's fun to study containers starting with "unshare" and "clone".
They could still keep their qemu fork and everything so that the driver compatibility is still top-notch, but at least they would not require out of tree kernel modules, and VirtualBox would also be concurrently usable with other KVM users.