----- Original Message -----
> This affects oVirt Node a bit (which is why I've got an interest) but
> also relevant to vdsm running on vanilla hypervisors like F16.
> Two decisions we need to get acks on:
> 1. Location of local storage for vdsm is /rhev in the RHEV product.
> Suggestion is to change this to one of:
/opt is used for apps
/var/lib is for app data, so it sounds to me like it should be /var/lib/vdsm
> 2. Naming of the management interface that vdsm uses. Right now in
> RHEV product, vdsm renames the mgmt interface to 'rhevm'.
> Suggestions fall into a few categories (thx to danpb for putting
> these options together)
> - brN, where N is assigned incrementally from 0. eg
> - brN, where N is chosen based on the last digit from the
> physical interface enslaved eg
> - brDEV, where DEV is the name of the physical interface
all of the above won't really fly as they do not withstand the requirement for
a fixed name across a cluster of hypervisors.
> - brNET, where NET is a logical name of the network
> brmgmt containing eth0 as the management LAN
> brguest containing eth7 as the guest <-> guest LAN
> brinet containing eth42 as the guest <-> internet LAN
> briscsi containing vlan7.3 for the iSCSI storage LAN
above convention is problematic due to the 'br' prefix which complicates flows
like migration if physical representation of the logical network is not
consistent across nodes (i.e. bridge on host a called brmgmt and nic alias on
host b called ???)
Specifying the logical name alone seems the easiest path. i.e. 'vdsm' or
> My personal vote is to use:
> /opt/ovirt rather than something off of the root filesystem, since
> will fit in with how we're going to enable plugins and writable
> of the filesystem in oVirt Node anyhow
> I also vote for interface naming like brNET, so brvdsm. Keeping in
> that the mgmt interface will not always be a bridge in the future, so
> the mgmt interface is _not_ a bridge, then 'vdsm' by itself would be
> good name. The br prefix should only be used if/when the vdsm
> is also a bridge.
> That's just my 2c, discuss on list and let's see if we can reach a
> consensus so we can make fwd progress.
> vdsm-devel mailing list
vdsm-devel mailing list