I missed the last line.
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:
- /etc/vdsm/vdsm.conf - for user configuration. We install this file if
missing, and never touch this file during upgrade.
- /etc/vdsm/vdsm.conf.d/ - for admin drop-in conf files.
- /usr/lib/vdsm/vdsm.conf.d/ - for vendor drop-in configuration files.
- /var/run/vdsm/vdsm.conf.d/ - for admin temporary configuration.
Files with a .conf suffix can be placed into any of the vdsm.conf.d drop-in
The priority of the configuration files is determined by the number prefix
of each file.
On Wed, Feb 15, 2017 at 4:43 PM, Gianluca Cecchi <gianluca.cec...@gmail.com>
> On Wed, Feb 15, 2017 at 4:23 PM, Marcin Mirecki <mmire...@redhat.com>
>> It should not have any negative interference on configuration issues,
>> it could have a negative impact on performace of your ovirtmgmt network,
>> in case your OVN traffic saturates the connection.
>> >Cannot edit Interface. External network cannot be changed while the
>> virtual machine is running.
>> The error message is incorrect (it predates the introduction of nic
>> It is enough to unplug/plug the nic before/after doing changes (the nic
>> must be in the unplugged state to change it).
>> As far as I know there is already a bug reported about the error message
>> being incorrect.
> OK. I just verified that it works as you described, thanks
>> >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?
>> 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.
> OK, but at least the packets would be invisible to the ovirtmgmt network
> 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...
> Does this make sense in this way for the tunnel too or nothing at all?
>> >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?
>> The tunnel should take care of the isolation, so I don't think it would
>> add any value.
>> >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?
>> 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.
>> 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).
> Ah, I see. I think the relevant lines in vdsm.conf are:
> # Comma-separated list of fnmatch-patterns for host nics to be hidden
> # from vdsm.
> # hidden_nics = w*,usb*
> # Comma-separated list of fnmatch-patterns for host bonds to be hidden
> # from vdsm.
> # hidden_bonds =
> # Comma-separated list of fnmatch-patterns for host vlans to be hidden
> # from vdsm. vlan names must be in the format "dev.VLANID" (e.g.
> # eth0.100, em1.20, eth2.200). vlans with alternative names must be
> # hidden from vdsm (e.g. eth0.10-fcoe, em1.myvlan100, vlan200)
> # hidden_vlans =
> 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?
Users mailing list