This affects oVirt Node a bit (which is why I've got an interest) but is 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: /ovirt /var/lib/ovirt /opt/ovirt
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
br0 containing eth0 br1 containing eth7 br2 containing eth42 br4 containing vlan7.3 for VLAN 3 on eth7
- brN, where N is chosen based on the last digit from the physical interface enslaved eg
br0 containing eth0 br7 containing eth7 br42 containing eth42 br7.3 containing vlan7.3 for VLAN 3 on eth7
- brDEV, where DEV is the name of the physical interface
breth0 containing eth0 breth7 containing eth7 breth42 containing eth42 breth7.3 containing vlan7.3 on VLAN 3 on eth7
- 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
My personal vote is to use:
/opt/ovirt rather than something off of the root filesystem, since this will fit in with how we're going to enable plugins and writable portions of the filesystem in oVirt Node anyhow
I also vote for interface naming like brNET, so brvdsm. Keeping in mind that the mgmt interface will not always be a bridge in the future, so if the mgmt interface is _not_ a bridge, then 'vdsm' by itself would be a good name. The br prefix should only be used if/when the vdsm interface is also a bridge.
That's just my 2c, discuss on list and let's see if we can reach a quick consensus so we can make fwd progress.
Cheers,
Perry
----- Original Message -----
This affects oVirt Node a bit (which is why I've got an interest) but is also relevant to vdsm running on vanilla hypervisors like F16.
Two decisions we need to get acks on:
- Location of local storage for vdsm is /rhev in the RHEV product. Suggestion is to change this to one of: /ovirt /var/lib/ovirt /opt/ovirt
/opt is used for apps /var/lib is for app data, so it sounds to me like it should be /var/lib/vdsm
- 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 something.
My personal vote is to use:
/opt/ovirt rather than something off of the root filesystem, since this will fit in with how we're going to enable plugins and writable portions of the filesystem in oVirt Node anyhow
I also vote for interface naming like brNET, so brvdsm. Keeping in mind that the mgmt interface will not always be a bridge in the future, so if the mgmt interface is _not_ a bridge, then 'vdsm' by itself would be a good name. The br prefix should only be used if/when the vdsm interface is also a bridge.
That's just my 2c, discuss on list and let's see if we can reach a quick consensus so we can make fwd progress.
Cheers,
Perry _______________________________________________ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
/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 LANabove 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
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 LANabove 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
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 LANabove 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
rename rhevm bridge to vdsm http://gerrit.ovirt.org/#change,311
Now is required to change engine/backend to accepted 'vdsm' as bridge.
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 LANabove 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
rename rhevm bridge to vdsm http://gerrit.ovirt.org/#change,311
Now is required to change engine/backend to accepted 'vdsm' as bridge.
New suggestion from Dan:
/var/run/vdsm may be better since nothing there is expected to be relevant after reboot. http://www.pathname.com/fhs/pub/fhs-2.3.html#VARRUNRUNTIMEVARIABLEDATA
thoughts?
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 LANabove 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
rename rhevm bridge to vdsm
I think we should plan to allow providing the name of the vdsm network as part of bootstrapping.
http://gerrit.ovirt.org/#change,311
Now is required to change engine/backend to accepted 'vdsm' as bridge.
New suggestion from Dan:
/var/run/vdsm may be better since nothing there is expected to be relevant after reboot. http://www.pathname.com/fhs/pub/fhs-2.3.html#VARRUNRUNTIMEVARIABLEDATA
i thought perry was talking about the path for local storage, not the mount point of all storage domains (which is relevant as well here, and i agree /var/run make more sense for it). but need to cover the path for local storage in ovirt-node. I'm not sure i like /var/lib/vdsm as it is just a path for a local storage domain of files. so /var/lib/images, or /var/lib/vdsm/images would be better.
----- Original Message -----
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
rename rhevm bridge to vdsm
I think we should plan to allow providing the name of the vdsm network as part of bootstrapping.
http://gerrit.ovirt.org/#change,311
Now is required to change engine/backend to accepted 'vdsm' as bridge.
New suggestion from Dan:
/var/run/vdsm may be better since nothing there is expected to be relevant after reboot. http://www.pathname.com/fhs/pub/fhs-2.3.html#VARRUNRUNTIMEVARIABLEDATA
i thought perry was talking about the path for local storage, not the mount point of all storage domains (which is relevant as well here, and i agree /var/run make more sense for it). but need to cover the path for local storage in ovirt-node.
afaik that is /data and /data2
I'm not sure i like /var/lib/vdsm as it is just a path for a local storage domain of files. so /var/lib/images, or /var/lib/vdsm/images would be better. _______________________________________________ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
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@lists.stg.fedorahosted.org
-
abaron＠redhat.com -
Dan Kenigsberg -
Douglas Schilling Landgraf -
iheim＠redhat.com -
Perry Myers