<p dir="ltr">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.</p>
<p dir="ltr">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.</p>
<p dir="ltr">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.</p>
<p dir="ltr">Thanks<br>
- Trey</p>
<div class="gmail_quote">On Aug 4, 2014 5:53 AM, "ybronhei" <<a href="mailto:ybronhei@redhat.com">ybronhei@redhat.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 07/31/2014 01:28 AM, Trey Dockendorf wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'm running ovirt nodes that are stock CentOS 6.5 systems with VDSM<br>
installed. I am using iSER to do iSCSI over RDMA and to make that<br>
work I have to modify /etc/vdsm/vdsm.conf to include the following:<br>
<br>
[irs]<br>
iscsi_default_ifaces = iser,default<br>
<br>
I've noticed that any time I upgrade a node from the engine web<br>
interface that changes to vdsm.conf are wiped out. I don't know if<br>
this is being done by the configuration code or by the vdsm package.<br>
Is there a more reliable way to ensure changes to vdsm.conf are NOT<br>
removed automatically?<br>
</blockquote>
<br>
Hey,<br>
<br>
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<br>
<br>
Douglas can you verify that with node upgrade? might be specific to that flow..<br>
<br>
Trey, can file a bugzilla on that and describe your steps there?<br>
<br>
Thanks<br>
<br>
Yaniv Bronhaim,<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Thanks,<br>
- Trey<br>
______________________________<u></u>_________________<br>
Users mailing list<br>
<a href="mailto:Users@ovirt.org" target="_blank">Users@ovirt.org</a><br>
<a href="http://lists.ovirt.org/mailman/listinfo/users" target="_blank">http://lists.ovirt.org/<u></u>mailman/listinfo/users</a><br>
<br>
</blockquote>
<br>
<br>
-- <br>
Yaniv Bronhaim.<br>
</blockquote></div>