libvirt users - May 2020 - Re: Unit libvirtd.service could not be found. on VM

if I understand correctly then I shouldn't have installed libvirt-daemon on
the guests VMs?


On Tue, May 12, 2020 at 2:34 PM Daniel P. Berrangé <berrange@redhat.com>
wrote:
> On Tue, May 12, 2020 at 02:25:29PM +0300, Dana Elfassy wrote:
> > Thanks, Daniel
> > I verified I had libvirt-daemon rpm on my laptop and reloaded its
units,
> > but that didn't solve the issue. I then checked the vms-
> > libvirt-daemon rpm was indeed missing on my vms. After I installed it
&
> > reloaded its unit files libvirtd.service was found, but as I started
it,
> > the error 'operation failed: pool 'default' already exists
with uuid
> > a42beb54-839e-437b-a48e-d06f6100205c' appeared again on my laptop.
> > I'm not sure if I was supposed to install libvirt-daemon rpm on
the vms?
> if
> > it was needed - how do I resolve the error now? and any idea why it
was
> > missing? I never had to install it before
> > if not - if you have any other thoughts/suggestions I'll be glad
to hear
> :)
>
> If virt-manager is connecting to the host OS, there's no reason to
install
> libvirtd in any guests VM.
>
> The error message is telling you that the 'default' storage pool
already
> exists - "virsh pool-list" should show it.
>
> THe existance of this error message in the logs is not in itself a problem.
> It may just show that virt-manager is blindly trying to create the pool
> even when it already exists.
>
> Regards,
> Daniel
> --
> |: https://berrange.com      -o-
> https://www.flickr.com/photos/dberrange :|
> |: https://libvirt.org         -o-
> https://fstop138.berrange.com :|
> |: https://entangle-photo.org    -o-
> https://www.instagram.com/dberrange :|
>
>

On Tue, May 12, 2020 at 02:41:42PM +0300, Dana Elfassy
wrote:
> if I understand correctly then I shouldn't have installed
libvirt-daemon on
> the guests VMs?
Correct


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

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

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
>
>