[ovirt-devel] Re: libvirt can't start in a non-TLS environment after host install

[Marcin Sobczyk]

Hi,

this issue should be fixed by:

https://gerrit.ovirt.org/#/q/topic:remove-non-socket-activation-libvirt-support+(status:open+OR+status:merged)

if you could provide any feedback whether it works for you, that would 
be great.


Thanks, Marcin

On 3/24/20 2:34 PM, Milan Zamazal wrote:

Marcin Sobczyk  writes:


Hi,

On 3/24/20 10:28 AM, Milan Zamazal wrote:

Hi, I've experienced a problem with host deploy and oVirt master last
week in an environment with TLS disabled.  When I install/reinstall a
4.4 host, it removes the following options from
/etc/libvirt/libvirtd.conf:

ca_file="/etc/pki/vdsm/certs/cacert.pem"
cert_file="/etc/pki/vdsm/certs/vdsmcert.pem"
key_file="/etc/pki/vdsm/keys/vdsmkey.pem"

As a result, libvirt refuses to start, complaining about missing
certificates and keys in their default locations.

And this is where things start to get blurry...
Since you're trying out a non-TLS environment I guess that vdsm-tool
added to 'libvirtd.conf':

auth_tcp: "none"
listen_tcp: 1
listen_tls: 0

right?

Yes.


But supervdsmd's service definition still requires libvirtd-tls.socket
and that might cause libvirtd to complain.
Could you please try manually removing the libvirtd-tls.socket
dependency, disabling this unit and see if libvirtd still complains?

If I disable the dependency, libvirt/Vdsm starts happily.


Does anybody who uses a non-TLS environment experience the same problem?
Can it be related to the fact that we require libvirtd-tls service from
the split libvirtd services now?

(Yes, I know TLS should always be used, but that is a shared development
environment where TLS is disabled for whatever reason.)

Thanks,
Milan


___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/devel@ovirt.org/message/DJKFCUAY3YQA2RG6PUFSQDF7UYUF7GYE/

[ovirt-devel] ovirt-engine has been re-tagged (ovirt-engine-4.4.0_beta2)

[Tal Nisan]

Note: this a retag, the former ovirt-engine-4.4.0_beta2 tag now points to
the rebuild
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/devel@ovirt.org/message/CFTNDQT7EEP4NJFVCMQPYFURAESYV6QL/

[ovirt-devel] Re: Why is vdsm enabled by default?

[Yuval Turgeman]

Marcin's work looks great on my (manual) tests, in addition to that we
disabled ovirt-vmconsole-host-sshd.service [1] in NGN as it fails to start
due to a missing host key, until it gets added to the engine, which enables
the service as well.

[1] https://gerrit.ovirt.org/#/c/108173/

On Thu, Apr 2, 2020 at 4:50 PM Marcin Sobczyk  wrote:

>
>
> On 2/3/20 3:11 PM, Martin Perina wrote:
>
>
>
> On Sun, Feb 2, 2020 at 9:11 AM Yedidyah Bar David  wrote:
>
>> On Sat, Feb 1, 2020 at 11:26 PM Nir Soffer  wrote:
>> >
>> > On Thu, Jan 30, 2020 at 12:19 PM Dan Kenigsberg 
>> wrote:
>> >>
>> >> On Thu, Jan 30, 2020 at 9:57 AM Yedidyah Bar David 
>> wrote:
>> >> >
>> >> > On Tue, Jan 28, 2020 at 1:20 PM Amit Bawer 
>> wrote:
>> >> >>
>> >> >>
>> >> >>
>> >> >> On Tue, Jan 28, 2020 at 12:40 PM Yedidyah Bar David <
>> d...@redhat.com> wrote:
>> >> >>>
>> >> >>> On Tue, Jan 28, 2020 at 12:11 PM Amit Bawer 
>> wrote:
>> >> 
>> >>  From my limited experience, the usual flow for most users is
>> deploying/upgrading a host and installing vdsm from the engine UI on the
>> hypervisor machine.
>> >> >>>
>> >> >>>
>> >> >>> You are right, for non-hosted-engine hosts. For hosted-engine, at
>> least the first host, you first install stuff on it (including vdsm), then
>> deploy, and only then have an engine. If for any reason you reboot in the
>> middle, you might run into unneeded problems, due to vdsm starting at boot.
>> >> >>>
>> >> 
>> >>  In case of manual installations by non-users, it is accustomed to
>> run "vdsm-tool configure --force" after step 3 and then reboot.
>> >> >>>
>> >> >>>
>> >> >>> I didn't know that, sorry, but would not want to do that either,
>> for hosted-engine. I'd rather hosted-engine deploy to do that, at the right
>> point. Which it does :-)
>> >> >>>
>> >> 
>> >>  Having a host on which vdsm is not running by default renders it
>> useless for ovirt, unless it is explicitly set to be down from UI under
>> particular circumstances.
>> >> >>>
>> >> >>>
>> >> >>> Obviously, for an active host. If it's not active, and is
>> rebooted, not sure we need vdsm to start - even if it's already
>> added/configured/etc (but e.g. put in maintenance). But that's not my
>> question - I don't mind enabling vdsmd as part of host-deploy, so that vdsm
>> would start if a host in maintenance is rebooted. I only ask why it should
>> be enabled by the rpm installation.
>> >> >>
>> >> >>
>> >> >> Hard to tell, this dates back to commit
>> d45e6827f38d36730ec468d31d905f21878c7250 and commit
>> c01a733ce81edc2c51ed3426f1424c93917bb106 before that, in which both did not
>> specify a reason.
>> >> >
>> >> >
>> >> > Adding Dan. Dan - was it enabled by default in sysv? I think not.
>> Was there an explicit requirement/decision to enable it on the move to
>> systemd? If not, is it ok to keep it disabled by default and enable when
>> needed (host-deploy)?
>> >>
>> >> Oh dear, I have only very vague memories right now. I do believe that
>> >> we have always has (the equivalent of) vdsm enable. At one point we
>> >> moved that to an rpm preset per explicit request from Fedora. But my
>> >> gut feeling is that there was not a very good reason to have it that
>> >> way. It might have been only a case of contagiousness: old versions of
>> >> ovirt-host-deploy do not have the logic to enable vdsm, so vdsm had to
>> >> have it itself, so nobody bothered to fix ovirt-host-deploy for the
>> >> next version, and here we are 5 years later.
>> >
>> >
>> > It does not make sense to enable vdsm unless it was configured,
>>
>> Indeed
>>
>> > and we certainly don't
>> > want to configure it automatically,
>>
>> We do, currently :-((
>>
>> > so vdsm should not be enabled by default.
>>
>> :-)
>>
>> >
>> > But someone needs to update host deploy code to enable vdsm before we
>> can change
>> > vdsm deployment.
>>
>> We always did, in otopi ovirt-host-deploy. A quick grep in the ansible
>> code does not find for me this.
>>
>> I am glad we managed to reach a consensus, Thanks :-)
>>
>> Filed these now:
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=1797284 [RFE] enable vdsm
>> services during deploy
>> https://bugzilla.redhat.com/show_bug.cgi?id=1797287 [RFE] vdsm should
>> be disabled by default
>>
>>
> I vaguely remember that in the past VDSM needed to be enabled by default
> due to NGN image creation.
> Yuval/Sandro, is it still needed?
>
> If not, of course we can change VDSM packaging and host deploy flow ...
>
> I posted https://gerrit.ovirt.org/#/c/108098/ to disable vdsm's autostart
> after installation.
> Actually, due to recent issues with NGN image creation the last of the
> whole topic should be tested:
>
>
> https://gerrit.ovirt.org/#/q/topic:remove-non-socket-activation-libvirt-support+(status:open+OR+status:merged)
>
>
>
> >
>> >> >> But the rpm post installation should also configure vdsm, at least
>> on a fresh install [1], so it makes sense (at least to me) that it is okay
>> to enable it by default since 

[ovirt-devel] Re: Why is vdsm enabled by default?

[Marcin Sobczyk]

On 2/3/20 3:11 PM, Martin Perina wrote:



On Sun, Feb 2, 2020 at 9:11 AM Yedidyah Bar David > wrote:


On Sat, Feb 1, 2020 at 11:26 PM Nir Soffer mailto:nsof...@redhat.com>> wrote:
>
> On Thu, Jan 30, 2020 at 12:19 PM Dan Kenigsberg
mailto:dan...@redhat.com>> wrote:
>>
>> On Thu, Jan 30, 2020 at 9:57 AM Yedidyah Bar David
mailto:d...@redhat.com>> wrote:
>> >
>> > On Tue, Jan 28, 2020 at 1:20 PM Amit Bawer mailto:aba...@redhat.com>> wrote:
>> >>
>> >>
>> >>
>> >> On Tue, Jan 28, 2020 at 12:40 PM Yedidyah Bar David
mailto:d...@redhat.com>> wrote:
>> >>>
>> >>> On Tue, Jan 28, 2020 at 12:11 PM Amit Bawer
mailto:aba...@redhat.com>> wrote:
>> 
>>  From my limited experience, the usual flow for most users
is deploying/upgrading a host and installing vdsm from the engine
UI on the hypervisor machine.
>> >>>
>> >>>
>> >>> You are right, for non-hosted-engine hosts. For
hosted-engine, at least the first host, you first install stuff on
it (including vdsm), then deploy, and only then have an engine. If
for any reason you reboot in the middle, you might run into
unneeded problems, due to vdsm starting at boot.
>> >>>
>> 
>>  In case of manual installations by non-users, it is
accustomed to run "vdsm-tool configure --force" after step 3 and
then reboot.
>> >>>
>> >>>
>> >>> I didn't know that, sorry, but would not want to do that
either, for hosted-engine. I'd rather hosted-engine deploy to do
that, at the right point. Which it does :-)
>> >>>
>> 
>>  Having a host on which vdsm is not running by default
renders it useless for ovirt, unless it is explicitly set to be
down from UI under particular circumstances.
>> >>>
>> >>>
>> >>> Obviously, for an active host. If it's not active, and is
rebooted, not sure we need vdsm to start - even if it's already
added/configured/etc (but e.g. put in maintenance). But that's not
my question - I don't mind enabling vdsmd as part of host-deploy,
so that vdsm would start if a host in maintenance is rebooted. I
only ask why it should be enabled by the rpm installation.
>> >>
>> >>
>> >> Hard to tell, this dates back to commit
d45e6827f38d36730ec468d31d905f21878c7250 and commit
c01a733ce81edc2c51ed3426f1424c93917bb106 before that, in which
both did not specify a reason.
>> >
>> >
>> > Adding Dan. Dan - was it enabled by default in sysv? I think
not. Was there an explicit requirement/decision to enable it on
the move to systemd? If not, is it ok to keep it disabled by
default and enable when needed (host-deploy)?
>>
>> Oh dear, I have only very vague memories right now. I do
believe that
>> we have always has (the equivalent of) vdsm enable. At one point we
>> moved that to an rpm preset per explicit request from Fedora.
But my
>> gut feeling is that there was not a very good reason to have it
that
>> way. It might have been only a case of contagiousness: old
versions of
>> ovirt-host-deploy do not have the logic to enable vdsm, so vdsm
had to
>> have it itself, so nobody bothered to fix ovirt-host-deploy for the
>> next version, and here we are 5 years later.
>
>
> It does not make sense to enable vdsm unless it was configured,

Indeed

> and we certainly don't
> want to configure it automatically,

We do, currently :-((

> so vdsm should not be enabled by default.

:-)

>
> But someone needs to update host deploy code to enable vdsm
before we can change
> vdsm deployment.

We always did, in otopi ovirt-host-deploy. A quick grep in the ansible
code does not find for me this.

I am glad we managed to reach a consensus, Thanks :-)

Filed these now:

https://bugzilla.redhat.com/show_bug.cgi?id=1797284 [RFE] enable vdsm
services during deploy
https://bugzilla.redhat.com/show_bug.cgi?id=1797287 [RFE] vdsm should
be disabled by default


I vaguely remember that in the past VDSM needed to be enabled by 
default due to NGN image creation.

Yuval/Sandro, is it still needed?

If not, of course we can change VDSM packaging and host deploy flow ...
I posted https://gerrit.ovirt.org/#/c/108098/ to disable vdsm's 
autostart after installation.
Actually, due to recent issues with NGN image creation the last of the 
whole topic should be tested:


https://gerrit.ovirt.org/#/q/topic:remove-non-socket-activation-libvirt-support+(status:open+OR+status:merged)




>
>> >> But the rpm post installation should also configure vdsm, at
least on a fresh install [1], so it makes sense (at least to me)
that it is okay to enable it by default since you have all setup
for a regular usage.
>> >>
>> >> [1]