<div dir="ltr"><div>I missed the last line.<br></div><br>A vdsm configuration is created from a default vdsm configuration file under /etc/vdsm/vdsm.conf. Then it reads conf files from drop-in dirs and updates the configuration according to the files:<br><br>- /etc/vdsm/vdsm.conf - for user configuration. We install this file if missing, and never touch this file during upgrade.<br>- /etc/vdsm/vdsm.conf.d/ - for admin drop-in conf files.<br>- /usr/lib/vdsm/vdsm.conf.d/ - for vendor drop-in configuration files.<br>- /var/run/vdsm/vdsm.conf.d/ - for admin temporary configuration.<br><br>Files with a .conf suffix can be placed into any of the vdsm.conf.d drop-in directories.<br><br>The priority of the configuration files is determined by the number prefix of each file.<br><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 15, 2017 at 4:43 PM, Gianluca Cecchi <span dir="ltr"><<a href="mailto:gianluca.cecchi@gmail.com" target="_blank">gianluca.cecchi@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="">On Wed, Feb 15, 2017 at 4:23 PM, Marcin Mirecki <span dir="ltr"><<a href="mailto:mmirecki@redhat.com" target="_blank">mmirecki@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><div><div><div>It should not have any negative interference on configuration issues,<br></div><div>but<br></div>it could have a negative impact on performace of your ovirtmgmt network, in case your OVN traffic saturates the connection.<span class="m_-5454301817933469684gmail-"><br><br>>Cannot edit Interface. External network cannot be changed while the virtual machine is running.<br></span></div>The error message is incorrect (it predates the introduction of nic hotplugging)<br></div>It is enough to unplug/plug the nic before/after doing changes (the nic must be in the unplugged state to change it).<br></div><div>As far as I know there is already a bug reported about the error message being incorrect.<br></div></div></div></blockquote><div><br></div></span><div>OK. I just verified that it works as you described, thanks</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div></div><span class="m_-5454301817933469684gmail-"><div>>In the sense that the tunnel basically already realizes the isolation
from the ovirtmgmt network itself (what usually we do making vlans)
without >interfering in case I have a great exchange of data for example
over the tunnel between 2 VMs placed on different hosts?<br></div></span></div><div><div>If the traffic going over the tunnel saturates that link, it will interfere with with your ovirtmgm traffic. For testing this setup should be ok, I would not recommend it for production.</div></div></div></blockquote><div><br></div></span><div>OK, but at least the packets would be invisible to the ovirtmgmt network</div><div>I mean, typically on the same adapter you put separate vlans to segregate traffic. This doesn't give you the double of the bandwidth but the isolation of the network so that it doesn't to go and inspect the packet to see what is the target and so on... </div><div>Does this make sense in this way for the tunnel too or nothing at all?</div><span class=""><div> </div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><span class="m_-5454301817933469684gmail-"><br><br>>BTW: does it make sense to create another vlan on the bonding (that is
already setup with vlans), assigning an ip on the hosts and then use it?
<br></span></div><div>The tunnel should take care of the isolation, so I don't think it would add any value.<span class="m_-5454301817933469684gmail-"><br><br>>The same question could also apply to a general case where for example
my hosts have to integrate into a dedicated lan in the infrastructure
(eg for backup or monitoring or what else)... would I configure this lan
from oVirt or better from hosts themselves? <br></span></div><div></div><div>Any configuration changes made manually would cause ovirt to see them as unsynchronized. To do it cleanly you would have to hide the nics used for this by adding them to 'hidden_nic' in vdsm configuration (nics ignored by ovirt). Let me know if you want more information on this.<br></div><div>If you need a network to be used by the host, a better solution would be to just create a separate network from ovirt (a non-vm network if you don't need a bridge on top of the nic).</div></div></div></blockquote><div><br></div></span><div>Ah, I see. I think the relevant lines in vdsm.conf are:</div><div><br></div><div><div># Comma-separated list of fnmatch-patterns for host nics to be hidden</div><div># from vdsm.</div><div># hidden_nics = w*,usb*</div><div><br></div><div># Comma-separated list of fnmatch-patterns for host bonds to be hidden</div><div># from vdsm.</div><div># hidden_bonds =</div><div><br></div><div># Comma-separated list of fnmatch-patterns for host vlans to be hidden</div><div># from vdsm. vlan names must be in the format "dev.VLANID" (e.g.</div><div># eth0.100, em1.20, eth2.200). vlans with alternative names must be</div><div># hidden from vdsm (e.g. eth0.10-fcoe, em1.myvlan100, vlan200)</div><div># hidden_vlans =</div></div><div><br></div><div>And in case I have to create some file of type 01_hidden.conf in /etc/vdsm/vdsm.conf.d/ to preserve across upgrades, correct?</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>Gianluca</div></font></span></div></div></div>
</blockquote></div><br></div>