Re: [Users] networking: basic vlan help

2014-01-27 Thread Juan Pablo Lorier
Hi Mike,

I'd like to say that though setting ovirtmgmt as non vm as a default
should be nice, it won't be enough as it won't allow to use mixed
traffic in other interfaces either, so the way I see it, the fix should
be to add this ability to ovirt. I can't make my mind to think what a
big corporation may need in security restrictions, but as a small
company, I'm willing to take the risk of a hardly probable security
breach in favor of been able to use untagged and tagged vlans on the
same nic.
Regards,

On 26/01/14 11:40, Mike Kolesnik wrote:
 - Original Message -
 On 01/23/2014 08:34 PM, Juan Pablo Lorier wrote:
 Hi Itamar,

 I don't know if I get your post right, but to me, it seems that if so
 many users hit the same rock, it should mean that this should be
 documented somewhere visible and in my opinion, push on getting bug
 1049476 https://bugzilla.redhat.com/show_bug.cgi?id=1049476 solved asap.
 Regards,
 1. yes, too many issues on this one, hinting we should provide better
 text explaining this in the UI.

 2. the bug you referenced[1]
 Bug 1049476 - [RFE] Mix untagged and tagged Logical Networks on the same NIC

 is actually supported, as long as the untagged logical network is not a
 VM network (so VMs associated with it would not be able to see/create
 other logical networks traffic).

 3. considering how prevalent this is, maybe we should allow doing this,
 even for VM networks, with a big red warning, rather than block it,
 which seems to be failing everyone.
 Besides that it's technically not possible in the way we currently use the 
 Linux Bridge [1],
 I'm not sure what's to gain from representing a single flat network with 
 multiple representations.

 Seems to me like there may be a couple different points here:
 * ovirtmgmt is VM network by default - should be configurable on setup and/or 
 DC creation.
   If it's such a prevalent issue, we should consider a default of non VM 
 network (users can create a flat network and use it quite easily anyway, if 
 they want).
 * if people want to represent different L3 networks on the same L2 network, 
 it is worthwhile to design a proper solution

 Either way, I wouldn't push for allowing multiple bridged networks on the 
 same physical interface (or bond).

 [1] and also not allowed in OpenStack Neutron IIUC.

 cc-ing some more folks for their thoughts.


 [1] in the future, please use number-name formatso not everyone would
 have to open it to understand

 ___
 Users mailing list
 Users@ovirt.org
 http://lists.ovirt.org/mailman/listinfo/users


___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [Users] networking: basic vlan help

2014-01-27 Thread Lior Vernia


On 26/01/14 15:40, Mike Kolesnik wrote:
 - Original Message -
 On 01/23/2014 08:34 PM, Juan Pablo Lorier wrote:
 Hi Itamar,

 I don't know if I get your post right, but to me, it seems that if so
 many users hit the same rock, it should mean that this should be
 documented somewhere visible and in my opinion, push on getting bug
 1049476 https://bugzilla.redhat.com/show_bug.cgi?id=1049476 solved asap.
 Regards,

 1. yes, too many issues on this one, hinting we should provide better
 text explaining this in the UI.

 2. the bug you referenced[1]
 Bug 1049476 - [RFE] Mix untagged and tagged Logical Networks on the same NIC

 is actually supported, as long as the untagged logical network is not a
 VM network (so VMs associated with it would not be able to see/create
 other logical networks traffic).

 3. considering how prevalent this is, maybe we should allow doing this,
 even for VM networks, with a big red warning, rather than block it,
 which seems to be failing everyone.
 
 Besides that it's technically not possible in the way we currently use the 
 Linux Bridge [1],
 I'm not sure what's to gain from representing a single flat network with 
 multiple representations.
 
 Seems to me like there may be a couple different points here:
 * ovirtmgmt is VM network by default - should be configurable on setup and/or 
 DC creation.
   If it's such a prevalent issue, we should consider a default of non VM 
 network (users can create a flat network and use it quite easily anyway, if 
 they want).

From a UX point of view I don't think this would be desireable. I think
it's convenient for a new user to be able to use just the one default
network for everything (including connection to VMs).

 * if people want to represent different L3 networks on the same L2 network, 
 it is worthwhile to design a proper solution
 
 Either way, I wouldn't push for allowing multiple bridged networks on the 
 same physical interface (or bond).
 
 [1] and also not allowed in OpenStack Neutron IIUC.
 

 cc-ing some more folks for their thoughts.


 [1] in the future, please use number-name formatso not everyone would
 have to open it to understand

 ___
 Users mailing list
 Users@ovirt.org
 http://lists.ovirt.org/mailman/listinfo/users

 ___
 Users mailing list
 Users@ovirt.org
 http://lists.ovirt.org/mailman/listinfo/users
 
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [Users] networking: basic vlan help

2014-01-26 Thread Lior Vernia


On 23/01/14 18:35, Itamar Heim wrote:
 On 01/23/2014 05:59 PM, Assaf Muller wrote:
 If you enable VLAN tagging on the management network, which is configured
 on eth0 (Which also provides internet access from my understanding) then
 you will connectivity as (I assume) your physical switches aren't
 configured
 for VLANs.

 For an all-in-one, what I would suggest is the following procedure:
 On your PC, create a dummy NIC via:
 sudo ip link add dev dummy_0 type dummy
 sudo ip link set dev dummy_0 up

 It's important that the name will be in the dummy_* format.

 Following that, go back to the GUI, select the host and hit Refresh
 Host Capabilities.

 You should see the new dummy_0 device as a host NIC.

 Create a VM network, and under the host Network Interfaces tab hit
 Setup Host Networks.

 Drag and drop the new VM network on dummy_0 (Don't give dummy_0 a boot
 protocol or an IP address
 in the edit network dialog).

 At this point you should be able to attach VM vNICs' to the new VM
 network and they won't
 be physically connected to any other network, but they'll be able to
 talk amongst themselves.


 The private network feature is planned* for oVirt 3.5, so in the
 future you'll be able
 to just define a network as a private one and everything will work
 automatically.

 * No promises!


 Assaf Muller, Cloud Networking Engineer
 Red Hat

 - Original Message -
 From: Robert Story rst...@tislabs.com
 To: users users@ovirt.org
 Sent: Thursday, January 23, 2014 5:44:25 PM
 Subject: [Users] networking: basic vlan help

 Hello again,

 I'm new to VLANs and have a few questions. Right now I just have the mgmt
 interface (bridged with eth0) on my all-in-one oVirt test setup. I
 want to
 separate some VMs from the public facing net, which I think means that
 they
 need to be on a different VLAN.  I created two new networks, pubX and
 privY, with vlan ids X and Y, but couldn't assign them to eth0 because
 the
 current mgmt network is non-VLAN. I was about to enable VLAN tagging
 on the
 mgmt network, but I wanted to make sure that doing so wouldn't do
 anything
 to eth0 that would disrupt access to it (I only have remote access and
 don't
 want to lock myself out).  Also, if it is safe, does the mgmt vlan tag id
 matter? is 0 the right value?

 Any/all help, hints, tips or references to examples/links greatly
 appreciated.


 Robert

 ___
 Users mailing list
 Users@ovirt.org
 http://lists.ovirt.org/mailman/listinfo/users
 ___
 Users mailing list
 Users@ovirt.org
 http://lists.ovirt.org/mailman/listinfo/users

 
 wouldn't disabling 'vm network' on the mgmt network to simply allow the
 VLAN'd networks for VMs be simpler?

Yes, this is an alternative to VLAN-tagging the mgmt network. And
segregation from the outer world could be achieved as proposed by
Robert using VLANs, if switches are configured properly.

 also, since this question/use-case came up several times past 2 weeks -
 do we have a good enough user feedback on why user can't attach a
 logical network to the same interface, suggesting there is a non-vlan'd
 network visible to VMs, and that if they want to use VLAN'd networks on
 the same nic, they should disable the 'vm network' role on the
 non-vlan'd network?
 

When trying to put such networks together via the Setup Networks dialog,
users are currently informed that non-tagged VM networks can't exist on
the same interface as tagged VM networks, and are advised to detach the
non-tagged network.

If this appears to be insufficient, I could replace it by a suggestion
to configure it as non-VM, or add that to the existing suggestion, but
we're kinda short on real-estate in the status panel of that dialog (and
that's a lot of information to absorb in one error).
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [Users] networking: basic vlan help

2014-01-26 Thread Mike Kolesnik
- Original Message -
 On 01/23/2014 08:34 PM, Juan Pablo Lorier wrote:
  Hi Itamar,
 
  I don't know if I get your post right, but to me, it seems that if so
  many users hit the same rock, it should mean that this should be
  documented somewhere visible and in my opinion, push on getting bug
  1049476 https://bugzilla.redhat.com/show_bug.cgi?id=1049476 solved asap.
  Regards,
 
 1. yes, too many issues on this one, hinting we should provide better
 text explaining this in the UI.
 
 2. the bug you referenced[1]
 Bug 1049476 - [RFE] Mix untagged and tagged Logical Networks on the same NIC
 
 is actually supported, as long as the untagged logical network is not a
 VM network (so VMs associated with it would not be able to see/create
 other logical networks traffic).
 
 3. considering how prevalent this is, maybe we should allow doing this,
 even for VM networks, with a big red warning, rather than block it,
 which seems to be failing everyone.

Besides that it's technically not possible in the way we currently use the 
Linux Bridge [1],
I'm not sure what's to gain from representing a single flat network with 
multiple representations.

Seems to me like there may be a couple different points here:
* ovirtmgmt is VM network by default - should be configurable on setup and/or 
DC creation.
  If it's such a prevalent issue, we should consider a default of non VM 
network (users can create a flat network and use it quite easily anyway, if 
they want).
* if people want to represent different L3 networks on the same L2 network, it 
is worthwhile to design a proper solution

Either way, I wouldn't push for allowing multiple bridged networks on the same 
physical interface (or bond).

[1] and also not allowed in OpenStack Neutron IIUC.

 
 cc-ing some more folks for their thoughts.
 
 
 [1] in the future, please use number-name formatso not everyone would
 have to open it to understand
 
 ___
 Users mailing list
 Users@ovirt.org
 http://lists.ovirt.org/mailman/listinfo/users
 
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [Users] networking: basic vlan help

2014-01-23 Thread Assaf Muller
If you enable VLAN tagging on the management network, which is configured
on eth0 (Which also provides internet access from my understanding) then
you will connectivity as (I assume) your physical switches aren't configured
for VLANs.

For an all-in-one, what I would suggest is the following procedure:
On your PC, create a dummy NIC via:
sudo ip link add dev dummy_0 type dummy
sudo ip link set dev dummy_0 up

It's important that the name will be in the dummy_* format.

Following that, go back to the GUI, select the host and hit Refresh Host 
Capabilities.

You should see the new dummy_0 device as a host NIC.

Create a VM network, and under the host Network Interfaces tab hit Setup Host 
Networks.

Drag and drop the new VM network on dummy_0 (Don't give dummy_0 a boot protocol 
or an IP address
in the edit network dialog).

At this point you should be able to attach VM vNICs' to the new VM network and 
they won't
be physically connected to any other network, but they'll be able to talk 
amongst themselves.


The private network feature is planned* for oVirt 3.5, so in the future 
you'll be able
to just define a network as a private one and everything will work 
automatically.

* No promises!


Assaf Muller, Cloud Networking Engineer 
Red Hat 

- Original Message -
From: Robert Story rst...@tislabs.com
To: users users@ovirt.org
Sent: Thursday, January 23, 2014 5:44:25 PM
Subject: [Users] networking: basic vlan help

Hello again,

I'm new to VLANs and have a few questions. Right now I just have the mgmt
interface (bridged with eth0) on my all-in-one oVirt test setup. I want to
separate some VMs from the public facing net, which I think means that they
need to be on a different VLAN.  I created two new networks, pubX and
privY, with vlan ids X and Y, but couldn't assign them to eth0 because the
current mgmt network is non-VLAN. I was about to enable VLAN tagging on the
mgmt network, but I wanted to make sure that doing so wouldn't do anything
to eth0 that would disrupt access to it (I only have remote access and don't
want to lock myself out).  Also, if it is safe, does the mgmt vlan tag id
matter? is 0 the right value?

Any/all help, hints, tips or references to examples/links greatly
appreciated.


Robert

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [Users] networking: basic vlan help

2014-01-23 Thread Robert Story
On Thu, 23 Jan 2014 10:59:57 -0500 (EST) Assaf wrote:
AM If you enable VLAN tagging on the management network, which is
AM configured on eth0 (Which also provides internet access from my
AM understanding) then you will connectivity as (I assume) your physical
AM switches aren't configured for VLANs.

I'm assuming will connectivity should have been will lose connectivity,
which is what I feared. I'm glad I asked!

AM For an all-in-one, what I would suggest is the following procedure:

Excellent, I'll try that. Thanks!

My next question is for future planning. There is a second interface
(eth1) with a separate physical network which only contains the engine,
nodes and the nfs server. 

 +--+
 | internet |-|---|--|
 +--+ ++  +---+  +---+   eth0
  | engine |  | node1 |  | node2 |
+-+   ++  +---+  +---+   eth1
| nfs |---|---|--|
+-+

Can the mgmt network be easily moved to eth1? Then the pubX would be
non-vlan on eth0, and mgmt + privY would be on eth1. If all the eth1
interfaces are connected to a dedicated/isolated switch, does that switch
need to explicitly support vlans, or does it matter?



Robert

--
Senior Software Engineer @ Parsons


signature.asc
Description: PGP signature
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [Users] networking: basic vlan help

2014-01-23 Thread Juan Pablo Lorier
Hi Robert,

You can use mgmt untagged but if it's a non-vm network. If you tag mgmt
network, ovirt will configure a vlan interface and add it to ovirtmgmt,
so you'll get a disruption when network gets restarted to take the changes.
Regards,
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [Users] networking: basic vlan help

2014-01-23 Thread Juan Pablo Lorier
Hi Itamar,

I don't know if I get your post right, but to me, it seems that if so
many users hit the same rock, it should mean that this should be
documented somewhere visible and in my opinion, push on getting bug
1049476 https://bugzilla.redhat.com/show_bug.cgi?id=1049476 solved asap.
Regards,
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [Users] networking: basic vlan help

2014-01-23 Thread Assaf Muller
Sorry, privY on eth1.

Assaf Muller, Cloud Networking Engineer 
Red Hat 


- Original Message -
From: Robert Story rst...@tislabs.com
To: Assaf Muller amul...@redhat.com
Cc: users users@ovirt.org
Sent: Thursday, January 23, 2014 7:11:50 PM
Subject: Re: [Users] networking: basic vlan help

On Thu, 23 Jan 2014 10:59:57 -0500 (EST) Assaf wrote:
AM If you enable VLAN tagging on the management network, which is
AM configured on eth0 (Which also provides internet access from my
AM understanding) then you will connectivity as (I assume) your physical
AM switches aren't configured for VLANs.

I'm assuming will connectivity should have been will lose connectivity,
which is what I feared. I'm glad I asked!

AM For an all-in-one, what I would suggest is the following procedure:

Excellent, I'll try that. Thanks!

My next question is for future planning. There is a second interface
(eth1) with a separate physical network which only contains the engine,
nodes and the nfs server. 

 +--+
 | internet |-|---|--|
 +--+ ++  +---+  +---+   eth0
  | engine |  | node1 |  | node2 |
+-+   ++  +---+  +---+   eth1
| nfs |---|---|--|
+-+

Can the mgmt network be easily moved to eth1? Then the pubX would be
non-vlan on eth0, and mgmt + privY would be on eth1. If all the eth1
interfaces are connected to a dedicated/isolated switch, does that switch
need to explicitly support vlans, or does it matter?



Robert

--
Senior Software Engineer @ Parsons
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [Users] networking: basic vlan help

2014-01-23 Thread Assaf Muller
What is the purpose of PubY on eth1?

Assaf Muller, Cloud Networking Engineer 
Red Hat 


- Original Message -
From: Robert Story rst...@tislabs.com
To: Assaf Muller amul...@redhat.com
Cc: users users@ovirt.org
Sent: Thursday, January 23, 2014 7:11:50 PM
Subject: Re: [Users] networking: basic vlan help

On Thu, 23 Jan 2014 10:59:57 -0500 (EST) Assaf wrote:
AM If you enable VLAN tagging on the management network, which is
AM configured on eth0 (Which also provides internet access from my
AM understanding) then you will connectivity as (I assume) your physical
AM switches aren't configured for VLANs.

I'm assuming will connectivity should have been will lose connectivity,
which is what I feared. I'm glad I asked!

AM For an all-in-one, what I would suggest is the following procedure:

Excellent, I'll try that. Thanks!

My next question is for future planning. There is a second interface
(eth1) with a separate physical network which only contains the engine,
nodes and the nfs server. 

 +--+
 | internet |-|---|--|
 +--+ ++  +---+  +---+   eth0
  | engine |  | node1 |  | node2 |
+-+   ++  +---+  +---+   eth1
| nfs |---|---|--|
+-+

Can the mgmt network be easily moved to eth1? Then the pubX would be
non-vlan on eth0, and mgmt + privY would be on eth1. If all the eth1
interfaces are connected to a dedicated/isolated switch, does that switch
need to explicitly support vlans, or does it matter?



Robert

--
Senior Software Engineer @ Parsons
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [Users] networking: basic vlan help

2014-01-23 Thread Robert Story
On Thu, 23 Jan 2014 13:33:07 -0500 (EST) Assaf wrote:
AM Sorry, privY on eth1.

For VM to VM communication that doesn't need to go over the public net..


Robert

--
Senior Software Engineer @ Parsons


signature.asc
Description: PGP signature
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [Users] networking: basic vlan help

2014-01-23 Thread Assaf Muller
Then the currently offered topology is to have ovirtmgmt on eth1 untagged, and 
non-VM, and have
privY as a VM, tagged network on eth1. That would require the physical switch 
to be VLAN-aware
and configured properly. oVirt wise you should have no problems using the GUI 
to move to that
topology once you've decided to do so.


Assaf Muller, Cloud Networking Engineer 
Red Hat 

- Original Message -
From: Robert Story rst...@tislabs.com
To: Assaf Muller amul...@redhat.com
Cc: users users@ovirt.org
Sent: Thursday, January 23, 2014 8:41:43 PM
Subject: Re: [Users] networking: basic vlan help

On Thu, 23 Jan 2014 13:33:07 -0500 (EST) Assaf wrote:
AM Sorry, privY on eth1.

For VM to VM communication that doesn't need to go over the public net..


Robert

--
Senior Software Engineer @ Parsons
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [Users] networking: basic vlan help

2014-01-23 Thread Juan Pablo Lorier
Hi Robert,

As I said before, you'll have network disruptions everytime you change
network topology and that's not because of ovirt but because you need to
restart network to set the new interfaces, routing tables and addresses,
etc.
This does not mean that you loose access to your hosts, if everything
goes right and you have everything set correctly, then after network
comes up, you should have access to your hosts. But if you have network
traffic, it will loose connectivity for a few seconds.
For the switch stuff, a simple switch will forward all packages
regardless of the vlan tag, so you won't need to configure anything.
These are the domestic or soho kind of switches. If you have a vlan
aware switch (most managed cheap ones have vlan features), then you'll
have to set vlans (either tagged or untagged) in the respective ports to
be able to get traffic from them.
Remember that marking a network in ovirt as a vlan network means that
it'll be accepting tagged traffic from that vlan. If you set your ports
to have a native vlan (untagged), then you should use non-vlan networks
in ovirt.
Regards,
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [Users] networking: basic vlan help

2014-01-23 Thread Itamar Heim

On 01/23/2014 08:34 PM, Juan Pablo Lorier wrote:

Hi Itamar,

I don't know if I get your post right, but to me, it seems that if so
many users hit the same rock, it should mean that this should be
documented somewhere visible and in my opinion, push on getting bug
1049476 https://bugzilla.redhat.com/show_bug.cgi?id=1049476 solved asap.
Regards,


1. yes, too many issues on this one, hinting we should provide better 
text explaining this in the UI.


2. the bug you referenced[1]
Bug 1049476 - [RFE] Mix untagged and tagged Logical Networks on the same NIC

is actually supported, as long as the untagged logical network is not a 
VM network (so VMs associated with it would not be able to see/create 
other logical networks traffic).


3. considering how prevalent this is, maybe we should allow doing this, 
even for VM networks, with a big red warning, rather than block it, 
which seems to be failing everyone.


cc-ing some more folks for their thoughts.


[1] in the future, please use number-name formatso not everyone would 
have to open it to understand


___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users