On Sat, Dec 10, 2011 at 09:39:44PM +0200, Itamar Heim wrote:
> On 12/09/2011 06:15 PM, Douglas Landgraf wrote:
> > On 12/08/2011 09:59 PM, Douglas Landgraf wrote:
> >> Hi,
> >>
> >> On 12/08/2011 02:31 PM, Douglas Landgraf wrote:
> >>> On 12/08/2011 10:14 AM, Perry Myers wrote:
> >>>>> /opt is used for apps
> >>>>> /var/lib is for app data, so it sounds to me like it should be 
> >>>>> /var/lib/vdsm
> >>>> /var/lib/vdsm is fine by me
> >>>>
> >>>>>>    - 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 something.
> >>>> No objections from me.  Using the br prefix is sort of for historical
> >>>> consistency reasons (i.e. bridges usually have names like br0, br1,
> >>>> etc), but I don't feel strongly about that.  So 'vdsm' is fine by me.
> >>>>
> >>>> So unless we have a major objection in the near future we'll use:
> >>>>
> >>>> /var/lib/vdsm
> >>>> and
> >>>> vdsm as the interface name
> >>> +1
> >>>
> >>
> >> Fell free to review:
> >>
> >> replace /rhev repository to /var/lib/vdsm
> >> http://gerrit.ovirt.org/#change,449
> >>

This may interest downstream only, but please note that ANY change of
/rhev makes live migration from rhev-3.0 to rhev-3.1 impossible. (Unless
libvirt gives destination Vdsm the opportunity to change device
<source>s)

> >> rename rhevm bridge to vdsm

Any change here makes 3.0->3.1 live migration pretty complex to
implement.

> 
> I think we should plan to allow providing the name of the vdsm network 
> as part of bootstrapping.
> 

Actually, it should not be just the name, it should be the whole setup:
users asked to be able to specify the vlan (and bonding) over which the
network is built.

BTW, it is a mistake to create a bridged management network by default.
We should probably create a nic alias for management IP, and leave the
nic free for optional bridged networks.

Dan.
_______________________________________________
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/vdsm-devel

Reply via email to