Thanks, Michal,
On my laptop I do have libguestfs and libvirt-daemon-qemu. both libvirtd.service and libvirtd.socket are running ok on my laptop
I just realized I haven't mentioned - my vms intend to serve as hosts themselves, and that's why they, too, need to have libvirtd.service running on them. 
up to recently I didn't have such a problem when I installed a vm on my laptop - libvirtd.service was found on it. I don't know exactly what caused this to change. Maybe it has something to do with configurations/ permissions of libvirt/ kvm?
Earlier, I'm not sure how, I managed to have libvirtd.service on a vm I created. it wasn't running, but at least it was there. I'm not sure what I have changed, but now I'm getting the message that the service could not be found again
Dana

On Wed, May 13, 2020 at 12:26 PM Michal Privoznik <mprivozn@redhat.com> wrote:
On 5/12/20 1:41 PM, Dana Elfassy wrote:
> if I understand correctly then I shouldn't have installed libvirt-daemon
> on the guests VMs?
>
>

Just a little background to Daniel's response. Libvirt and QEMU treat
guests as black boxes, to some extent. There are some exceptions to this
rule, when it comes to para-virtualization (that is when the guest knows
it is running virtualized and therefore can optimize some things). The
perfect example is virtio (which are para-virtualized devices like NIC,
disk, etc.). Depending on the guest the virtio drivers are either
already installed (majority of Linux distributions including CentOS, if
not all of them) or they have to be installed separately (Windows is
typical example).

Then, some tasks can be performed only if there is a small program
running inside the guest (so called guest agent), which listens for
incoming commands, executes them and sends the result back to libvirt.
In CentOS this is qemu-guest-agent RPM. As mentioned, guest agent needs
a channel to talk to libvirt which can be configured through virsh
directly [1], or in virt-manager (if not already present, but I guess
virt-install adds it automatically): Add hardware -> Channel -> Name:
org.qemu.guest_agent.0 -> Finish.

Some management applications have their own guest agents (e.g.
libguestfs), but I wouldn't worry about them - the management
application will configure them automatically; and you are not using
them anyway.


However, on the host the set of packages needed is different (note, you
don't need any virtio drivers - they are contained in qemu already; nor
you need the guest agent). libvirt-daemon-driver-qemu is the package
containing qemu driver for libvirt. However, in order to use other
features libvirt provides I suggest installing 'libvirt-daemon-kvm'
which drags in the rest of packages (e.g. storage driver, network
driver, etc.)

The host is also where you need libvirtd running (systemctl enable
libvirtd.service  or if you want to use socket activation then:
systemctl enable libvirtd.socket)

Michal


1: https://wiki.libvirt.org/page/Qemu_guest_agent