> On 12 Aug 2016, at 14:10, Francesco Romani <from...@redhat.com> wrote:
> 
> ----- Original Message -----
>> From: "Sandro Bonazzola" <sbona...@redhat.com>
>> To: "Gianluca Cecchi" <gianluca.cec...@gmail.com>, "Michal Skrivanek" 
>> <mskri...@redhat.com>, "Francesco Romani"
>> <from...@redhat.com>
>> Cc: "users" <users@ovirt.org>
>> Sent: Friday, August 12, 2016 2:01:54 PM
>> Subject: Re: [ovirt-users] oVirt updates available on host due to libvirt 
>> missing
>> 
>> On Fri, Aug 12, 2016 at 12:25 PM, Gianluca Cecchi <gianluca.cec...@gmail.com
>>> wrote:
>> 
>>> Hello,
>>> My self hosted engine environment was born in 3.6.0 in November with
>>> CentOS 7 on host and CentOS 7 appliance.
>>> I managed several updates applying 3.6.2, then 3.6.5, then 4.0.
>>> Now I'm at 4.0.2 final and in web admin gui I see a message regarding
>>> updates available on host (hosted_engine_1) that doesn't go away.
>>> The host usually was updated through "yum update" and not from the gui
>>> during updates described above.
>>> 
>>> In events pane it seems the problem is related with libvirt package
>>> 
>>> Host hosted_engine_1 has available updates: libvirt.
>>> 
>>> Actually at this moment the libvirt package (that seems actually a sort of
>>> meta-package) is not installed and I think has been never here. Situation
>>> is:
>>> 
>>> [root@ractor log]# rpm -qa|grep libvirt
>>> libvirt-daemon-driver-network-1.2.17-13.el7_2.5.x86_64
>>> libvirt-daemon-driver-interface-1.2.17-13.el7_2.5.x86_64
>>> libvirt-daemon-kvm-1.2.17-13.el7_2.5.x86_64
>>> libvirt-client-1.2.17-13.el7_2.5.x86_64
>>> libvirt-daemon-1.2.17-13.el7_2.5.x86_64
>>> libvirt-lock-sanlock-1.2.17-13.el7_2.5.x86_64
>>> libvirt-daemon-driver-storage-1.2.17-13.el7_2.5.x86_64
>>> libvirt-daemon-driver-qemu-1.2.17-13.el7_2.5.x86_64
>>> libvirt-daemon-driver-nodedev-1.2.17-13.el7_2.5.x86_64
>>> libvirt-python-1.2.17-2.el7.x86_64
>>> libvirt-daemon-config-nwfilter-1.2.17-13.el7_2.5.x86_64
>>> libvirt-daemon-driver-nwfilter-1.2.17-13.el7_2.5.x86_64
>>> libvirt-daemon-driver-secret-1.2.17-13.el7_2.5.x86_64
>>> [root@ractor log]#
>>> 
>>> If I run "yum install libvirt" I'm proposed:
>>> 
>>> Dependencies Resolved
>>> 
>>> ============================================================
>>> ========================================
>>> Package                              Arch          Version
>>>     Repository      Size
>>> ============================================================
>>> ========================================
>>> Installing:
>>> libvirt                              x86_64        1.2.17-13.el7_2.5
>>>     updates        119 k
>>> Installing for dependencies:
>>> libvirt-daemon-config-network        x86_64        1.2.17-13.el7_2.5
>>>     updates        120 k
>>> libvirt-daemon-driver-lxc            x86_64        1.2.17-13.el7_2.5
>>>     updates        747 k
>>> 
>>> Transaction Summary
>>> ============================================================
>>> ========================================
>>> Install  1 Package (+2 Dependent packages)
>>> 
>>> How to proceed?
> [...]
>> I t should be safe to install the dependencies. Adding Michal and Francesco
>> to confirm.
> 
> Not sure why it is proposed just now and not before.
> The -lxc package is not used by oVirt, so it will just sit there.
> The libvirt-daemon-config-network package should be harmless, it just contains
> the configuration fir libvirt's default bridge ‘virbr0'

well, harmless….though for a good reason we stopped pulling in “libvirt” as the 
metapackage brings problematic deps in certain cases (iirc it was due to 
ppc64le)
That’s why we depend on exactly just
libvirt-daemon-config-nwfilter libvirt-daemon-kvm libvirt-lock-sanlock 
libvirt-client libvirt-python

As Francesco says it’s mostly harmless, it’s just that on a truly clean 
environment “libvirt” wouldn’t be installed

Thanks,
michal

> 
> Bests,
> 
> -- 
> Francesco Romani
> RedHat Engineering Virtualization R & D
> Phone: 8261328
> IRC: fromani

_______________________________________________
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Reply via email to