Hi,
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:
[environment:enforce]
VDSM_CONFIG/vars/migration_max_bandwidth=str:300
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" <[email protected]>
To: "ybronhei" <[email protected]>
Cc: "users" <[email protected]>, "Fabian Deutsch" <[email protected]>, "Dan Kenigsberg"
<[email protected]>, "Itamar
Heim" <[email protected]>, "Douglas Landgraf" <[email protected]>, "Alon Bar-Lev"
<[email protected]>
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 <[email protected]> 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" <[email protected]> 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
[email protected]
http://lists.ovirt.org/mailman/listinfo/users
--
Yaniv Bronhaim.
_______________________________________________
Users mailing list
[email protected]
http://lists.ovirt.org/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected]
http://lists.ovirt.org/mailman/listinfo/users
