Virt-Manager is just a GUI for libvirt (virsh). You can achieve the same thing with virsh in the CLI. I’m not sure what your workflow is and how you actually use ansible. If you use it to create, delete, start and stop VMs, then obviously virt-man is not for you and you should probably use libvirt. But if you use ansible to configure VMs and test software after you create the VMs, then a GUI is not too bad.
LXC is a container technology, basically chroot on steroids. So compared to VMs, LXC is really lightweight. LXC can be configured to not use all the memory and cpu, but I don’t have experience with LXC tools on how to do that.
LXD is a container and VM orchestrator. In the back-end, it uses LXC, however, LXD makes administration of containers and VMs much easier and if needed, opens it to the network (as opposed to using ssh), so you can manage LXC containers from another device. LXD also has a VM feature, which leverages QEMU. The syntax is the same as for LXC, just that you add a --vm when creating VMs. So if you are going to create ansible playbooks yourself, LXD would simplify the task (you get 2-in-1 basically).
LXD also has an easy way to set the resource utilization of containers and VMs through profiles. You create a profile with standard ram, cpu, networks and permissions, basically like AWS EC2 (t2.medium, t2.large etc.) and you assign your containers and vms to that profile and they will only use as much as you give them, or unlimited if nothing is set on the profile. You may also create a profile for each container or vm, but that becomes unmanageable fast.
By editing a profile, you change the resources of all containers and vms (vms need to be restarted though for settings to apply). Or you can move a container to another profile and it will get new resources.
Finally, VMs, being complete virtual hardware will use all the resources you allocate them and use a bit of resources on your host to virtualize the hardware itself. A now standard feature in most hypervisors, including KVM that QEMU, and thus libvirt is using is called paravirtualization, which, by using a driver in your guest OS, you can reduce the amount of system resources used to emulate physical hardware. KVM calls those devices virtio. Lastly, VMs in libvirt will use all the resources they can get when it comes to RAM and storage.
Another feature developed for VMs is called Ballooning Device for RAM, so you may allocate less RAM to a VM and have it expand when the VM requires it, but I never use it, because I find it clunky. For disk, you have something called thin provisioning, which makes the VM only use as much storage as it actually uses. The double-edge sword of this is that you can overprovision your server. What that means is trick your VMs into having an overall bigger pool of resources then currently exist on the servers. If VMs behave, they may very well work and share together. But if suddenly all VMs decide to gobble up RAM, either some VMs will crash, or they will get suspended (likely the former). If the storage gets filled up and a VM thinks it has more storage than it does and tries to write to it, it will automatically get suspended by the hypervisor.
Now, after all that was explained, LXC and LXD function basically like ballooning for RAM and I believe thin provisioning for storage too (but I’m not certain on the later), but instead that’s the default and can not be changed, due to how LXC works. The amount of resources you allocate a container will not actually be permanently allocated to a container (not sure how it works for VMs in LXD though). You have your profile that sets the maximum limit of a container, but if the RAM is not used, you may use the rest on your host. But that gets you into the same issue with overprovisioning, so you have to keep in mind the total amount of resources containers have set in their profiles, but for LXC/LXD is not that big of an issue compared to VMs, they don’t tend to crash when they reach the RAM limit.
The only disadvantage I see by using LXD VMs is that I don’t think it can run other OSes than the images provided by
linuxcontainers.org. I think it may be possible to install things like Windows or BSD manually, then just clone the container, but I don’t know how one would do that, so if you are sometimes using OSes other than Linux in your testing, you have to keep this in mind.