[ovirt-users] Proper way to change and persist vdsm configuration options

Yuriy Demchenko demchenko.ya at gmail.com
Tue Oct 7 12:22:41 UTC 2014


sorry for digging up an old tread, but I have a problem with proposed 
way to preserve vdsm.conf between host redeployments
I've created a file /etc/ovirt-host-deploy.conf.d/migration-bw.conf on 
ovirt-engine with contents:
Then i've tried to add a new host via GUI - it was added, but with 
default vdsm.conf, i.e. without my custom option "migration_max_bandwidth"
Also tried to restart ovirt-engine and reinstalling host - same result, 
no custom options, only default vdsm.conf content.
Am i missing something?

Freshly installed ovirt 3.5-pre, centos 6.5 as engine, centos7 as hosts

Yuriy Demchenko

On 08/05/2014 10:45 PM, Alon Bar-Lev wrote:
> ----- Original Message -----
>> From: "Trey Dockendorf" <treydock at gmail.com>
>> To: "ybronhei" <ybronhei at redhat.com>
>> Cc: "users" <users at ovirt.org>, "Fabian Deutsch" <fabiand at redhat.com>, "Dan Kenigsberg" <danken at redhat.com>, "Itamar
>> Heim" <iheim at redhat.com>, "Douglas Landgraf" <dougsland at redhat.com>, "Alon Bar-Lev" <alonbl at redhat.com>
>> Sent: Tuesday, August 5, 2014 9:36:24 PM
>> Subject: Re: [ovirt-users] Proper way to change and persist vdsm configuration options
>> On Tue, Aug 5, 2014 at 12:32 PM, ybronhei <ybronhei at redhat.com> wrote:
>>> Hey,
>>> Just noticed something that I forgot about..
>>> before filing new BZ, see in ovirt-host-deploy README.environment [1] the
>>> section:
>>> VDSM/configOverride(bool) [True]
>>>      Override vdsm configuration file.
>>> changing it to false will keep your vdsm.conf file as is after deploying
>>> the
>>> host again (what happens after node upgrade)
>>> [1]
>>> https://github.com/oVirt/ovirt-host-deploy/blob/master/README.environment
>>> please check if that what you meant..
>>> Thanks,
>>> Yaniv Bronhaim.
>> I was unaware of that package.  I will check that out as that seems to
>> be what I am looking for.
>> I have not filed this in BZ and will hold off pending
>> ovirt-host-deploy.  If you feel a BZ is still necessary then please do
>> file one and I would be happy to provide input if it would help.
>> Right now this is my workflow.
>> 1. Foreman provisions bare-metal server with CentOS 6.5
>> 2. Once provisioned and system rebooted Puppet applies puppet-ovirt
>> [1] module that adds the necessary yum repos
> and should stop here..
>> , and installs packages.
>> Part of my Puppet deployment is basic things like sudo management
>> (vdsm's sudo is account for), sssd configuration, and other aspects
>> that are needed by every system in my infrastructure.  Part of the
>> ovirt::node Puppet class is managing vdsm.conf, and in my case that
>> means ensuring iSER is enabled for iSCSI over IB.
> you can create a file /etc/ovirt-host-deploy.conf.d/40-xxx.conf
> ---
> VDSM_CONFIG/section/key=str:content
> ---
> this will create a proper vdsm.conf when host-deploy is initiated.
> you should now use the rest api to initiate host-deploy.
>> 3. Once host is online and has had the full Puppet catalog applied I
>> log into ovirt-engine web interface and add those host (pulling it's
>> data via the Foreman provider).
> right, but you should let this process install packages and manage configuration.
>> What I've noticed is that after step #3, after a host is added by
>> ovirt-engine, the vdsm.conf file is reset to default and I have to
>> reapply Puppet before it can be used as the one of my Data Storage
>> Domains requires iSER (not available over TCP).
> right, see above.
>> What would be the workflow using ovirt-host-deploy?  Thus far I've had
>> to piece together my workflow based on the documentation and filling
>> in blanks where possible since I do require customizations to
>> vdsm.conf and the documented workflow of adding a host via web UI does
>> not allow for such customization.
>> Thanks,
>> - Trey
>> [1] - https://github.com/treydock/puppet-ovirt (README not fully
>> updated as still working out how to use Puppet with oVirt)
>>> On 08/05/2014 08:12 AM, Trey Dockendorf wrote:
>>>> I'll file BZ.  As far as I can recall this has been an issue since 3.3.x
>>>> as
>>>> I have been using Puppet to modify values and have had to rerun Puppet
>>>> after installing a node via GUI and when performing update from GUI.
>>>> Given
>>>> that it has occurred when VDSM version didn't change on the node it seems
>>>> likely to be something being done by Python code that bootstraps a node
>>>> and
>>>> performs the other tasks.  I won't have any systems available to test with
>>>> for a few days.  New hardware specifically for our oVirt deployment is on
>>>> order so should be able to more thoroughly debug and capture logs at that
>>>> time.
>>>> Would using vdsm-reg be a better solution for adding new nodes?  I only
>>>> tried using vdsm-reg once and it went very poorly...lots of missing
>>>> dependencies not pulled in from yum install I had to install manually via
>>>> yum.  Then the node was auto added to newest cluster with no ability to
>>>> change the cluster.  Be happy to debug that too if there's some docs that
>>>> outline the expected behavior.
>>>> Using vdsm-reg or something similar seems like a better fit for puppet
>>>> deployed nodes, as opposed to requiring GUI steps to add the node.
>>>> Thanks
>>>> - Trey
>>>> On Aug 4, 2014 5:53 AM, "ybronhei" <ybronhei at redhat.com> wrote:
>>>>> On 07/31/2014 01:28 AM, Trey Dockendorf wrote:
>>>>>> I'm running ovirt nodes that are stock CentOS 6.5 systems with VDSM
>>>>>> installed.  I am using iSER to do iSCSI over RDMA and to make that
>>>>>> work I have to modify /etc/vdsm/vdsm.conf to include the following:
>>>>>> [irs]
>>>>>> iscsi_default_ifaces = iser,default
>>>>>> I've noticed that any time I upgrade a node from the engine web
>>>>>> interface that changes to vdsm.conf are wiped out.  I don't know if
>>>>>> this is being done by the configuration code or by the vdsm package.
>>>>>> Is there a more reliable way to ensure changes to vdsm.conf are NOT
>>>>>> removed automatically?
>>>>> Hey,
>>>>> vdsm.conf shouldn't wiped out and shouldn't changed at all during
>>>>> upgrade.
>>>>> other related conf files (such as libvirtd.conf) might be overrided to
>>>>> keep
>>>>> defaults configurations for vdsm. but vdsm.conf should persist with
>>>>> user's
>>>>> modification. from my check, regular yum upgrade doesn't touch vdsm.conf
>>>>> Douglas can you verify that with node upgrade? might be specific to that
>>>>> flow..
>>>>> Trey, can file a bugzilla on that and describe your steps there?
>>>>> Thanks
>>>>> Yaniv Bronhaim,
>>>>>> Thanks,
>>>>>> - Trey
>>>>>> _______________________________________________
>>>>>> Users mailing list
>>>>>> Users at ovirt.org
>>>>>> http://lists.ovirt.org/mailman/listinfo/users
>>>>> --
>>>>> Yaniv Bronhaim.
> _______________________________________________
> Users mailing list
> Users at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users

More information about the Users mailing list