10:07 a.m.
------_=_NextPart_001_01CF0D11.E17769E3
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hello,
I am evaluating oVirt as a replacement/alternative to VMware deployments =
we typically do. I have installed and all-in-one setup on a test box =
(which itself used to be an ESXi server), but it only has one NIC. I =
trying to duplicate our typical configuration we do in VMware, which is =
this:
1.) we create several "port groups" on the vSwitch, each assigned a =
VLAN ID, such as:
- VLAN001 (VLAN ID: 1)
- VLAN002 (VLAN ID: 2)
- VLAN009 (VLAN ID: 9)
- VLAN010 (VLAN ID: 10)
- VLAN200 (VLAN ID: 200)
- TRUNK (VLAN ID: 4095 - in VMware-world, VLAN ID "4095" is "all =
VLANS" and basically just passes the VLANs through to whatever is =
attached to the port group for the VM to handle)
2.) We assign VMs to port groups appropriate for the VLAN they are =
part of.
3.) The only VM that has a NIC assigned to the "TRUNK" port group is =
the firewall (which is Linux), and we create VLAN interfaces on it =
(i.e., "eth1.1", "eth1.2", "eth1.10", "eth1.200").
The firewall VM acts =
as the router between the various VLANs.
To replicate the above in oVirt, I created logical networks for each =
VLAN, and assigned the appropriate VLAN ID. It seems oVirt/KVM does not =
have an equivalent for VMware's VLAN ID of "4095", so after some =
searching around, so for the "TRUNK" network, I left it with no VLAN =
assigned. Because i cannot add VLAN and non-VLAN networks to the same =
physical NIC, after some searching around, it looks like I may have to =
utilise two NICS: one for the VLAN networks and one for the "TRUNK" =
network.
Because, at this point, I am not yet concerned with making the test VMs =
I will be setting up be accessible from outside the virtual lab =
environment (i.e., everything will communicate within my oVirt =
server/network for now), I am trying to make use of "dummy" interfaces, =
but I am not sure the best way to make use of this. I am able to create =
the dummy* interfaces and have them show up in oVirt, but I am not sure =
of how they should be setup. Here is what I am *thinking* should be =
done, but want to make sure it is correct before getting too deep:
- I will use the physical NIC for management, therefore the =
"ovirtmgmt" bridge with eth0 assigned to it will remain as-is
- Create two dummy interfaces: "dummy0" and "dummy1"
- Create a new bridge, "ovirtvm" and assign "dummy0" and
"dummy1" to =
it
- Attach the VLAN-enabled networks to "dummy0"
- Attach the "TRUNK" network to "dummy1"
Would the above be the way to go about this? The one thing I am not =
sure of is whether or not having no VLAN assigned (on the "TRUNK" =
network) accomplishes the same this as the "VLAN ID 4095" in VMware: =
will oVirt/KVM just pass the traffic through for the VM attached to it =
to deal with?
Thanks for reading this far, and I appreciate any help you might be able =
to lend in the above.
-Alan
------_=_NextPart_001_01CF0D11.E17769E3
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7654.12">
<TITLE>Networking questions (LONG)</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT SIZE=3D2>Hello,<BR>
<BR>
I am evaluating oVirt as a replacement/alternative to VMware deployments =
we typically do. I have installed and all-in-one setup on a test =
box (which itself used to be an ESXi server), but it only has one =
NIC. I trying to duplicate our typical configuration we do in =
VMware, which is this:<BR>
<BR>
1.) we create several "port groups" on the vSwitch, =
each assigned a VLAN ID, such as:<BR>
<BR>
- VLAN001 (VLAN ID: 1)<BR>
- VLAN002 (VLAN ID: 2)<BR>
- VLAN009 (VLAN ID: 9)<BR>
- VLAN010 (VLAN ID: 10)<BR>
- VLAN200 (VLAN ID: 200)<BR>
- TRUNK (VLAN ID: 4095 - in
VMware-world, =
VLAN ID "4095" is "all VLANS" and basically just =
passes the VLANs through to whatever is attached to the port group for =
the VM to handle)<BR>
<BR>
2.) We assign VMs to port groups appropriate for the VLAN they =
are part of.<BR>
3.) The only VM that has a NIC assigned to the "TRUNK" =
port group is the firewall (which is Linux), and we create VLAN =
interfaces on it (i.e., "eth1.1", "eth1.2", =
"eth1.10", "eth1.200"). The firewall VM acts
=
as the router between the various VLANs.<BR>
<BR>
To replicate the above in oVirt, I created logical networks for each =
VLAN, and assigned the appropriate VLAN ID. It seems oVirt/KVM =
does not have an equivalent for VMware's VLAN ID of "4095", so =
after some searching around, so for the "TRUNK" network, I =
left it with no VLAN assigned. Because i cannot add VLAN and =
non-VLAN networks to the same physical NIC, after some searching around, =
it looks like I may have to utilise two NICS: one for the VLAN networks =
and one for the "TRUNK" network.<BR>
<BR>
Because, at this point, I am not yet concerned with making the test VMs =
I will be setting up be accessible from outside the virtual lab =
environment (i.e., everything will communicate within my oVirt =
server/network for now), I am trying to make use of "dummy" =
interfaces, but I am not sure the best way to make use of this. I =
am able to create the dummy* interfaces and have them show up in oVirt, =
but I am not sure of how they should be setup. Here is what I am =
*thinking* should be done, but want to make sure it is correct before =
getting too deep:<BR>
<BR>
- I will use the physical NIC for management, therefore the =
"ovirtmgmt" bridge with eth0 assigned to it will remain =
as-is<BR>
- Create two dummy interfaces: "dummy0" and =
"dummy1"<BR>
- Create a new bridge, "ovirtvm" and assign =
"dummy0" and "dummy1" to it<BR>
- Attach the VLAN-enabled networks to "dummy0"<BR>
- Attach the "TRUNK" network to
"dummy1"<BR>
<BR>
Would the above be the way to go about this? The one thing I am =
not sure of is whether or not having no VLAN assigned (on the =
"TRUNK" network) accomplishes the same this as the "VLAN =
ID 4095" in VMware: will oVirt/KVM just pass the traffic through =
for the VM attached to it to deal with?<BR>
<BR>
Thanks for reading this far, and I appreciate any help you might be able =
to lend in the above.<BR>
<BR>
-Alan<BR>
</FONT>
</P>
</BODY>
</HTML>
------_=_NextPart_001_01CF0D11.E17769E3--
10:22 a.m.
One other question to add: If I do indeed ned to create a new bridge
("ovirtvm" in my example), I do not want to assign any IPs to it, nor
any of the logical networks I create. When I did try this in my
"fooling around", oVirt would not let me save the changes, giving me
an error about network parameters not correct (I have the host shut
down a the moment, so I can get the exact message, but if necessary, I
can get it for you when I get in to our shop in the morning)
Thanks! :-)
-Alan
11:28 a.m.
Just as a quick shot:
it is possible to configure it the way you want (ip-less bridges), but I
can't exactly tell you what you're doing wrong atm.
ip-less bridges work here with vlans and stuff, so keep trying or
post more info about your setup :-)
Am 09.01.2014 09:22, schrieb Alan Murrell:
One other question to add: If I do indeed ned to create a new
bridge
("ovirtvm" in my example), I do not want to assign any IPs to it, nor
any of the logical networks I create. When I did try this in my
"fooling around", oVirt would not let me save the changes, giving me an
error about network parameters not correct (I have the host shut down a
the moment, so I can get the exact message, but if necessary, I can get
it for you when I get in to our shop in the morning)
--
Mit freundlichen Grüßen / Regards
Sven Kieske
Systemadministrator
Mittwald CM Service GmbH & Co. KG
Königsberger Straße 6
32339 Espelkamp
T: +49-5772-293-100
F: +49-5772-293-333
https://www.mittwald.de
Geschäftsführer: Robert Meyer
St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen
Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen
10:53 p.m.
Hello Alan,
On 09/01/14 10:07, Alan Murrell wrote:
Hello,
I am evaluating oVirt as a replacement/alternative to VMware deployments
we typically do. I have installed and all-in-one setup on a test box
(which itself used to be an ESXi server), but it only has one NIC. I
trying to duplicate our typical configuration we do in VMware, which is
this:
1.) we create several "port groups" on the vSwitch, each assigned a
VLAN ID, such as:
- VLAN001 (VLAN ID: 1)
- VLAN002 (VLAN ID: 2)
- VLAN009 (VLAN ID: 9)
- VLAN010 (VLAN ID: 10)
- VLAN200 (VLAN ID: 200)
- TRUNK (VLAN ID: 4095 - in VMware-world, VLAN ID "4095" is "all
VLANS" and basically just passes the VLANs through to whatever is
attached to the port group for the VM to handle)
2.) We assign VMs to port groups appropriate for the VLAN they are
part of.
3.) The only VM that has a NIC assigned to the "TRUNK" port group is
the firewall (which is Linux), and we create VLAN interfaces on it
(i.e., "eth1.1", "eth1.2", "eth1.10",
"eth1.200"). The firewall VM acts
as the router between the various VLANs.
To replicate the above in oVirt, I created logical networks for each
VLAN, and assigned the appropriate VLAN ID. It seems oVirt/KVM does not
have an equivalent for VMware's VLAN ID of "4095", so after some
searching around, so for the "TRUNK" network, I left it with no VLAN
assigned. Because i cannot add VLAN and non-VLAN networks to the same
physical NIC, after some searching around, it looks like I may have to
utilise two NICS: one for the VLAN networks and one for the "TRUNK" network.
That is true. One non-VLAN network can in fact sit on the same NIC with
VLAN networks, but it has to be non-VM.
However, I'm not sure that you in fact need a "TRUNK" VM network in
oVirt. If you want your firewall VM to get all traffic from the VLANs,
you could create a vNIC for each network, to which you'll attach a
profile (oVirt's equivalent of port group if I'm not mistaken) of the
corresponding network. The host can remain with just the VLAN networks
attached to its NICs, without a designated "TRUNK".
This way the firewall VM will get something like "eth1" for VLAN 1,
"eth2" for VLAN 200 and so forth, which might be close enough to what
you described on your previous setup (oVirt currently doesn't allow
creating VLANs inside VMs). And if I correctly understood your needs it
will save you the trouble you described below (well, you would need the
one dummy interface).
Because, at this point, I am not yet concerned with making the test VMs
I will be setting up be accessible from outside the virtual lab
environment (i.e., everything will communicate within my oVirt
server/network for now), I am trying to make use of "dummy" interfaces,
but I am not sure the best way to make use of this. I am able to create
the dummy* interfaces and have them show up in oVirt, but I am not sure
of how they should be setup. Here is what I am *thinking* should be
done, but want to make sure it is correct before getting too deep:
- I will use the physical NIC for management, therefore the
"ovirtmgmt" bridge with eth0 assigned to it will remain as-is
- Create two dummy interfaces: "dummy0" and "dummy1"
- Create a new bridge, "ovirtvm" and assign "dummy0" and
"dummy1" to it
This is something that currently can't be done from within the oVirt
engine, but if my above suggestion works for you then it won't be needed.
- Attach the VLAN-enabled networks to "dummy0"
- Attach the "TRUNK" network to "dummy1"
Would the above be the way to go about this? The one thing I am not
sure of is whether or not having no VLAN assigned (on the "TRUNK"
network) accomplishes the same this as the "VLAN ID 4095" in VMware:
will oVirt/KVM just pass the traffic through for the VM attached to it
to deal with?
Thanks for reading this far, and I appreciate any help you might be able
to lend in the above.
-Alan
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
2:16 a.m.
Hello Lior,
Thank you for your reply.
Quoting "Lior Vernia" <lvernia(a)redhat.com>:
This way the firewall VM will get something like "eth1" for
VLAN 1,
"eth2" for VLAN 200 and so forth, which might be close enough to what
you described on your previous setup (oVirt currently doesn't allow
creating VLANs inside VMs). And if I correctly understood your needs it
will save you the trouble you described below (well, you would need the
one dummy interface).
That would be doable, except I am not sure if there is a limit to the
number of vNICs a VM could have and/or if there is an OS-level limit
to how many? It is also a bit "messier" IMO, but that is more of a
personal issue than a technical one, and one I could probably get over
:-)
When you say that oVirt currently doesn't allow creating VLANs inside
VMs, are you referring to the use of VLAN interfaces like I describe
(e.g., "eth1.1", "eth1.2", "eth1.10", etc.)? If so, is that
an oVirt
limitation, or a KVM one?
I have seen examples where one can create a "Trunk" with KVM and Open
vSwitch, and I thought for some reason oVirt used Open vSwitch, but
none of the commands I tried from the examples were found. A check of
<http://www.ovirt.org/Features/Node/OpenVSwitchSupport> shows that
indeed there does not appear to be any integration yet, and it is only
60% done :-(
With regards to using the dummy interfaces, I realised I probably do
not need to add them to a bridge, since they would be physical NICs in
production (this is just for testing). I initially did create the
"ovirtvm" bridge before I realised that, but have made them
"stand-alone" NICs with no IPs attached to them, but they are not
"green" in oVirt when I try to attach my logical networks to them
under "Networks > Hosts > vmhost01 > Setup Host Networks".
When I am in "Setup Host Networks", I see my dummy interfaces, but
they have a red dot instead of a green one (like what "eth0" has). I
can my logical networks to them, but the "Network Device Status" has a
red arrow pointing down. Here are my ifcfg-dummy* files:
--- ifcfg-dummy0 ---
DEVICE=dummy0
ONBOOT=yes
TYPE=Ethernet
DELAY=0
BOOTPROTO=none
NM_CONTROLLED=no
STP=no
--- ifcfg-dummy0 ---
My "ifcfg-dummy1" is identical, except of course it has
"DEVICE=dummy1" in it. The interfaces do come up on the host, but as
I said, in "Setup Host Networks" they have a red dot instead of a
green one. Perhaps I do need to assign an IP? I can maybe assign a
"dummy" one (i.e., one that I would never use)?
-Alan
10:44 a.m.
Hi Allan,
On 10/01/14 02:16, Alan Murrell wrote:
Hello Lior,
Thank you for your reply.
Sure, let's try to get that setup of yours working :)
Quoting "Lior Vernia" <lvernia(a)redhat.com>:
> This way the firewall VM will get something like "eth1" for VLAN 1,
> "eth2" for VLAN 200 and so forth, which might be close enough to what
> you described on your previous setup (oVirt currently doesn't allow
> creating VLANs inside VMs). And if I correctly understood your needs it
> will save you the trouble you described below (well, you would need the
> one dummy interface).
That would be doable, except I am not sure if there is a limit to the
number of vNICs a VM could have and/or if there is an OS-level limit to
how many? It is also a bit "messier" IMO, but that is more of a
personal issue than a technical one, and one I could probably get over :-)
oVirt does not enforce any sort of limit on the number of vNICs. I
personally don't know about KVM or your VMs' OS, but this should be
Googleable.
When you say that oVirt currently doesn't allow creating VLANs
inside
VMs, are you referring to the use of VLAN interfaces like I describe
(e.g., "eth1.1", "eth1.2", "eth1.10", etc.)? If so, is
that an oVirt
limitation, or a KVM one?
Yes, sorry, I realise now that my phrasing was only half-understandable.
I indeed meant that oVirt doesn't support attaching more than one
network to the same vNIC (be it VLAN-tagged or not). I doubt that this
is a KVM limitation (but I'm no expert on KVM), I think it's just
something that we haven't yet found a strong case for in oVirt.
I have seen examples where one can create a "Trunk" with
KVM and Open
vSwitch, and I thought for some reason oVirt used Open vSwitch, but none
of the commands I tried from the examples were found. A check of
<http://www.ovirt.org/Features/Node/OpenVSwitchSupport> shows that
indeed there does not appear to be any integration yet, and it is only
60% done :-(
I actually know nothing of the link you provided, but I can offer
alternatives.
If you REALLY want to use OVS with oVirt NOW, you could take advantage
of its integration with OpenStack Neutron. That would require you to
install another machine (should be possible on an all-in-one setup too)
as a Neutron server. This might go smoothly or it might cause you some
headaches.
http://www.ovirt.org/Features/Detailed_OSN_Integration
It will probably become possible in the future to use OVS with oVirt
directly (although I can't promise or commit on the time frame) by
leveraging a development process that's going on in VDSM networking
right now. In fact, if you're a developer you could help make it happen
and control the time frame yourself by contributing to an OVS backend.
http://www.ovirt.org/Feature/NetworkReloaded
With regards to using the dummy interfaces, I realised I probably do
not
need to add them to a bridge, since they would be physical NICs in
production (this is just for testing). I initially did create the
"ovirtvm" bridge before I realised that, but have made them
"stand-alone" NICs with no IPs attached to them, but they are not
"green" in oVirt when I try to attach my logical networks to them under
"Networks > Hosts > vmhost01 > Setup Host Networks".
When I am in "Setup Host Networks", I see my dummy interfaces, but they
have a red dot instead of a green one (like what "eth0" has). I can my
logical networks to them, but the "Network Device Status" has a red
arrow pointing down. Here are my ifcfg-dummy* files:
I'm not an expert on these things, but this "Down" status is basically
the "administrative" link state on the host. From my experience when
logical networks are attached via the Setup Networks dialog, it does go
up, although I haven't tried without an IP address. Also, it's worth
trying to see if the actual networking works even if the NIC shows as
down, or to ifup the NIC manually if it doesn't.
--- ifcfg-dummy0 ---
DEVICE=dummy0
ONBOOT=yes
TYPE=Ethernet
DELAY=0
BOOTPROTO=none
NM_CONTROLLED=no
STP=no
--- ifcfg-dummy0 ---
My "ifcfg-dummy1" is identical, except of course it has
"DEVICE=dummy1"
in it. The interfaces do come up on the host, but as I said, in "Setup
Host Networks" they have a red dot instead of a green one. Perhaps I do
need to assign an IP? I can maybe assign a "dummy" one (i.e., one that
I would never use)?
-Alan
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
1:32 p.m.
On Thu, Jan 09, 2014 at 10:53:25PM +0200, Lior Vernia wrote:
Hello Alan,
On 09/01/14 10:07, Alan Murrell wrote:
> Hello,
>
> I am evaluating oVirt as a replacement/alternative to VMware deployments
> we typically do. I have installed and all-in-one setup on a test box
> (which itself used to be an ESXi server), but it only has one NIC. I
> trying to duplicate our typical configuration we do in VMware, which is
> this:
>
> 1.) we create several "port groups" on the vSwitch, each assigned a
> VLAN ID, such as:
>
> - VLAN001 (VLAN ID: 1)
> - VLAN002 (VLAN ID: 2)
> - VLAN009 (VLAN ID: 9)
> - VLAN010 (VLAN ID: 10)
> - VLAN200 (VLAN ID: 200)
> - TRUNK (VLAN ID: 4095 - in VMware-world, VLAN ID "4095" is
"all
> VLANS" and basically just passes the VLANs through to whatever is
> attached to the port group for the VM to handle)
>
> 2.) We assign VMs to port groups appropriate for the VLAN they are
> part of.
> 3.) The only VM that has a NIC assigned to the "TRUNK" port group is
> the firewall (which is Linux), and we create VLAN interfaces on it
> (i.e., "eth1.1", "eth1.2", "eth1.10",
"eth1.200"). The firewall VM acts
> as the router between the various VLANs.
>
> To replicate the above in oVirt, I created logical networks for each
> VLAN, and assigned the appropriate VLAN ID. It seems oVirt/KVM does not
> have an equivalent for VMware's VLAN ID of "4095", so after some
> searching around, so for the "TRUNK" network, I left it with no VLAN
> assigned. Because i cannot add VLAN and non-VLAN networks to the same
> physical NIC, after some searching around, it looks like I may have to
> utilise two NICS: one for the VLAN networks and one for the "TRUNK"
network.
That is true. One non-VLAN network can in fact sit on the same NIC with
VLAN networks, but it has to be non-VM.
This was devised as a security constraint - otherwise, a VM attached to
the non-VLAN network could sniff traffic from another (VLAN) network.
However, it seems that this is exactly what you need - a special VM that
is designed to do just that.
And it's not only you: there's another recent request for lifting this
limitation:
Bug 1049476 - [RFE] Mix untagged and tagged Logical Networks on the
same NIC
However, I'm not sure that you in fact need a "TRUNK" VM network in
oVirt. If you want your firewall VM to get all traffic from the VLANs,
you could create a vNIC for each network, to which you'll attach a
profile (oVirt's equivalent of port group if I'm not mistaken) of the
corresponding network. The host can remain with just the VLAN networks
attached to its NICs, without a designated "TRUNK".
This way the firewall VM will get something like "eth1" for VLAN 1,
"eth2" for VLAN 200 and so forth, which might be close enough to what
you described on your previous setup (oVirt currently doesn't allow
creating VLANs inside VMs). And if I correctly understood your needs it
will save you the trouble you described below (well, you would need the
one dummy interface).
>
> Because, at this point, I am not yet concerned with making the test VMs
> I will be setting up be accessible from outside the virtual lab
> environment (i.e., everything will communicate within my oVirt
> server/network for now), I am trying to make use of "dummy" interfaces,
> but I am not sure the best way to make use of this. I am able to create
> the dummy* interfaces and have them show up in oVirt, but I am not sure
> of how they should be setup. Here is what I am *thinking* should be
> done, but want to make sure it is correct before getting too deep:
>
> - I will use the physical NIC for management, therefore the
> "ovirtmgmt" bridge with eth0 assigned to it will remain as-is
> - Create two dummy interfaces: "dummy0" and "dummy1"
> - Create a new bridge, "ovirtvm" and assign "dummy0" and
"dummy1" to it
This is something that currently can't be done from within the oVirt
engine, but if my above suggestion works for you then it won't be needed.
> - Attach the VLAN-enabled networks to "dummy0"
> - Attach the "TRUNK" network to "dummy1"
I do not understand what you are trying to do with dummy devices (after
all, they are not going to send any packet anywhere).
But if you are willing to mess with network configuration under the feet
of oVirt, you could do the following:
- create a network tagged with an id that is not really used in your
datacenter, say 999, and attach it to the host.
- build and install vdsm-hook-extnet rpm
- define a vnic profile using this network, and adding a custom propery
called "extnet" with the value of (say) "untagged".
- set up a bridge named "untagged" directly on top of your eth0 (say
"breth0")
- define a libvirt bridged network named "untagged", that uses
"breth0".
- attach the vnic of your firewall VM to your vnic profile.
Now, when you start up your firewall vm, the "extnet" hook gets into
action, and forces the firewall vm from the 999 network, into using your
hand-crafted network.
This all sounds a bit long and hacky, but I believe it would work. I'll
love to hear if it does.
>
> Would the above be the way to go about this? The one thing I am not
> sure of is whether or not having no VLAN assigned (on the "TRUNK"
> network) accomplishes the same this as the "VLAN ID 4095" in VMware:
> will oVirt/KVM just pass the traffic through for the VM attached to it
> to deal with?
Yes. Untagged network passes all ethernet frames to the VM, be them
tagged or not. Inside the VM you can further process them (It's less
clear to me how you intend to do the processing, and how would the
firewall would block offensive traffic from reaching "normal" VMs).
2:39 p.m.
Hi Dan,
I take the chance to ask; why is that the untagged IF can see the
traffic of the tagged vlans? Isn't that filtered at kernel level? Is
this a virtualization design limitation or is it down to the kernel?
I don't know how the kernel processes the packages, but I thought that
packages that arrives to the nic are filtered by the kernel and sent to
the respective vif (untagged to the "master" interface and tagged to the
.XX interfaces). I ask because other virtualization platforms don't have
this limitation and I wonder if it's because they "don't care" of
because they solved this somehow.
Regards,
On 10/01/14 09:32, Dan Kenigsberg wrote:
On Thu, Jan 09, 2014 at 10:53:25PM +0200, Lior Vernia wrote:
> Hello Alan,
>
> On 09/01/14 10:07, Alan Murrell wrote:
>> Hello,
>>
>> I am evaluating oVirt as a replacement/alternative to VMware deployments
>> we typically do. I have installed and all-in-one setup on a test box
>> (which itself used to be an ESXi server), but it only has one NIC. I
>> trying to duplicate our typical configuration we do in VMware, which is
>> this:
>>
>> 1.) we create several "port groups" on the vSwitch, each assigned a
>> VLAN ID, such as:
>>
>> - VLAN001 (VLAN ID: 1)
>> - VLAN002 (VLAN ID: 2)
>> - VLAN009 (VLAN ID: 9)
>> - VLAN010 (VLAN ID: 10)
>> - VLAN200 (VLAN ID: 200)
>> - TRUNK (VLAN ID: 4095 - in VMware-world, VLAN ID "4095" is
"all
>> VLANS" and basically just passes the VLANs through to whatever is
>> attached to the port group for the VM to handle)
>>
>> 2.) We assign VMs to port groups appropriate for the VLAN they are
>> part of.
>> 3.) The only VM that has a NIC assigned to the "TRUNK" port group is
>> the firewall (which is Linux), and we create VLAN interfaces on it
>> (i.e., "eth1.1", "eth1.2", "eth1.10",
"eth1.200"). The firewall VM acts
>> as the router between the various VLANs.
>>
>> To replicate the above in oVirt, I created logical networks for each
>> VLAN, and assigned the appropriate VLAN ID. It seems oVirt/KVM does not
>> have an equivalent for VMware's VLAN ID of "4095", so after some
>> searching around, so for the "TRUNK" network, I left it with no VLAN
>> assigned. Because i cannot add VLAN and non-VLAN networks to the same
>> physical NIC, after some searching around, it looks like I may have to
>> utilise two NICS: one for the VLAN networks and one for the "TRUNK"
network.
> That is true. One non-VLAN network can in fact sit on the same NIC with
> VLAN networks, but it has to be non-VM.
This was devised as a security constraint - otherwise, a VM attached to
the non-VLAN network could sniff traffic from another (VLAN) network.
However, it seems that this is exactly what you need - a special VM that
is designed to do just that.
And it's not only you: there's another recent request for lifting this
limitation:
Bug 1049476 - [RFE] Mix untagged and tagged Logical Networks on the
same NIC
> However, I'm not sure that you in fact need a "TRUNK" VM network in
> oVirt. If you want your firewall VM to get all traffic from the VLANs,
> you could create a vNIC for each network, to which you'll attach a
> profile (oVirt's equivalent of port group if I'm not mistaken) of the
> corresponding network. The host can remain with just the VLAN networks
> attached to its NICs, without a designated "TRUNK".
>
> This way the firewall VM will get something like "eth1" for VLAN 1,
> "eth2" for VLAN 200 and so forth, which might be close enough to what
> you described on your previous setup (oVirt currently doesn't allow
> creating VLANs inside VMs). And if I correctly understood your needs it
> will save you the trouble you described below (well, you would need the
> one dummy interface).
>
>> Because, at this point, I am not yet concerned with making the test VMs
>> I will be setting up be accessible from outside the virtual lab
>> environment (i.e., everything will communicate within my oVirt
>> server/network for now), I am trying to make use of "dummy"
interfaces,
>> but I am not sure the best way to make use of this. I am able to create
>> the dummy* interfaces and have them show up in oVirt, but I am not sure
>> of how they should be setup. Here is what I am *thinking* should be
>> done, but want to make sure it is correct before getting too deep:
>>
>> - I will use the physical NIC for management, therefore the
>> "ovirtmgmt" bridge with eth0 assigned to it will remain as-is
>> - Create two dummy interfaces: "dummy0" and "dummy1"
>> - Create a new bridge, "ovirtvm" and assign "dummy0" and
"dummy1" to it
> This is something that currently can't be done from within the oVirt
> engine, but if my above suggestion works for you then it won't be needed.
>
>> - Attach the VLAN-enabled networks to "dummy0"
>> - Attach the "TRUNK" network to "dummy1"
I do not understand what you are trying to do with dummy devices (after
all, they are not going to send any packet anywhere).
But if you are willing to mess with network configuration under the feet
of oVirt, you could do the following:
- create a network tagged with an id that is not really used in your
datacenter, say 999, and attach it to the host.
- build and install vdsm-hook-extnet rpm
- define a vnic profile using this network, and adding a custom propery
called "extnet" with the value of (say) "untagged".
- set up a bridge named "untagged" directly on top of your eth0 (say
"breth0")
- define a libvirt bridged network named "untagged", that uses
"breth0".
- attach the vnic of your firewall VM to your vnic profile.
Now, when you start up your firewall vm, the "extnet" hook gets into
action, and forces the firewall vm from the 999 network, into using your
hand-crafted network.
This all sounds a bit long and hacky, but I believe it would work. I'll
love to hear if it does.
>> Would the above be the way to go about this? The one thing I am not
>> sure of is whether or not having no VLAN assigned (on the "TRUNK"
>> network) accomplishes the same this as the "VLAN ID 4095" in VMware:
>> will oVirt/KVM just pass the traffic through for the VM attached to it
>> to deal with?
Yes. Untagged network passes all ethernet frames to the VM, be them
tagged or not. Inside the VM you can further process them (It's less
clear to me how you intend to do the processing, and how would the
firewall would block offensive traffic from reaching "normal" VMs).
3:42 p.m.
On Fri, Jan 10, 2014 at 10:39:20AM -0200, Juan Pablo Lorier wrote:
Hi Dan,
I take the chance to ask; why is that the untagged IF can see the
traffic of the tagged vlans? Isn't that filtered at kernel level? Is
this a virtualization design limitation or is it down to the kernel?
I don't know how the kernel processes the packages, but I thought that
packages that arrives to the nic are filtered by the kernel and sent to
the respective vif (untagged to the "master" interface and tagged to the
.XX interfaces). I ask because other virtualization platforms don't have
this limitation and I wonder if it's because they "don't care" of
because they solved this somehow.
I do not know how this is implemented elsewhere, but to the best of my
knowledge, the "master" interface sees tagged packets, too (which is the
basis of Alan's use case: he wants the trunk VM to see all traffic).
BTW, Alan, for this to actually work, you need to enable macspoofing on the
relevant nic. Yet another step on the hack I've outlined earlier.
Dan.
3:06 p.m.
On 01/10/2014 01:32 PM, Dan Kenigsberg wrote:
On Thu, Jan 09, 2014 at 10:53:25PM +0200, Lior Vernia wrote:
> Hello Alan,
>
> On 09/01/14 10:07, Alan Murrell wrote:
>> Hello,
>>
>> I am evaluating oVirt as a replacement/alternative to VMware deployments
>> we typically do. I have installed and all-in-one setup on a test box
>> (which itself used to be an ESXi server), but it only has one NIC. I
>> trying to duplicate our typical configuration we do in VMware, which is
>> this:
>>
>> 1.) we create several "port groups" on the vSwitch, each assigned a
>> VLAN ID, such as:
>>
>> - VLAN001 (VLAN ID: 1)
>> - VLAN002 (VLAN ID: 2)
>> - VLAN009 (VLAN ID: 9)
>> - VLAN010 (VLAN ID: 10)
>> - VLAN200 (VLAN ID: 200)
>> - TRUNK (VLAN ID: 4095 - in VMware-world, VLAN ID "4095" is
"all
>> VLANS" and basically just passes the VLANs through to whatever is
>> attached to the port group for the VM to handle)
>>
>> 2.) We assign VMs to port groups appropriate for the VLAN they are
>> part of.
>> 3.) The only VM that has a NIC assigned to the "TRUNK" port group
is
>> the firewall (which is Linux), and we create VLAN interfaces on it
>> (i.e., "eth1.1", "eth1.2", "eth1.10",
"eth1.200"). The firewall VM acts
>> as the router between the various VLANs.
>>
>> To replicate the above in oVirt, I created logical networks for each
>> VLAN, and assigned the appropriate VLAN ID. It seems oVirt/KVM does not
>> have an equivalent for VMware's VLAN ID of "4095", so after some
>> searching around, so for the "TRUNK" network, I left it with no VLAN
>> assigned. Because i cannot add VLAN and non-VLAN networks to the same
>> physical NIC, after some searching around, it looks like I may have to
>> utilise two NICS: one for the VLAN networks and one for the "TRUNK"
network.
>
> That is true. One non-VLAN network can in fact sit on the same NIC with
> VLAN networks, but it has to be non-VM.
This was devised as a security constraint - otherwise, a VM attached to
the non-VLAN network could sniff traffic from another (VLAN) network.
However, it seems that this is exactly what you need - a special VM that
is designed to do just that.
isn't that was promiscious mode (aka port mirroring) is for?
And it's not only you: there's another recent request for
lifting this
limitation:
Bug 1049476 - [RFE] Mix untagged and tagged Logical Networks on the
same NIC
>
> However, I'm not sure that you in fact need a "TRUNK" VM network in
> oVirt. If you want your firewall VM to get all traffic from the VLANs,
> you could create a vNIC for each network, to which you'll attach a
> profile (oVirt's equivalent of port group if I'm not mistaken) of the
> corresponding network. The host can remain with just the VLAN networks
> attached to its NICs, without a designated "TRUNK".
>
> This way the firewall VM will get something like "eth1" for VLAN 1,
> "eth2" for VLAN 200 and so forth, which might be close enough to what
> you described on your previous setup (oVirt currently doesn't allow
> creating VLANs inside VMs). And if I correctly understood your needs it
> will save you the trouble you described below (well, you would need the
> one dummy interface).
>
>>
>> Because, at this point, I am not yet concerned with making the test VMs
>> I will be setting up be accessible from outside the virtual lab
>> environment (i.e., everything will communicate within my oVirt
>> server/network for now), I am trying to make use of "dummy"
interfaces,
>> but I am not sure the best way to make use of this. I am able to create
>> the dummy* interfaces and have them show up in oVirt, but I am not sure
>> of how they should be setup. Here is what I am *thinking* should be
>> done, but want to make sure it is correct before getting too deep:
>>
>> - I will use the physical NIC for management, therefore the
>> "ovirtmgmt" bridge with eth0 assigned to it will remain as-is
>> - Create two dummy interfaces: "dummy0" and "dummy1"
>> - Create a new bridge, "ovirtvm" and assign "dummy0" and
"dummy1" to it
>
> This is something that currently can't be done from within the oVirt
> engine, but if my above suggestion works for you then it won't be needed.
>
>> - Attach the VLAN-enabled networks to "dummy0"
>> - Attach the "TRUNK" network to "dummy1"
I do not understand what you are trying to do with dummy devices (after
all, they are not going to send any packet anywhere).
But if you are willing to mess with network configuration under the feet
of oVirt, you could do the following:
- create a network tagged with an id that is not really used in your
datacenter, say 999, and attach it to the host.
- build and install vdsm-hook-extnet rpm
- define a vnic profile using this network, and adding a custom propery
called "extnet" with the value of (say) "untagged".
- set up a bridge named "untagged" directly on top of your eth0 (say
"breth0")
- define a libvirt bridged network named "untagged", that uses
"breth0".
- attach the vnic of your firewall VM to your vnic profile.
Now, when you start up your firewall vm, the "extnet" hook gets into
action, and forces the firewall vm from the 999 network, into using your
hand-crafted network.
This all sounds a bit long and hacky, but I believe it would work. I'll
love to hear if it does.
>>
>> Would the above be the way to go about this? The one thing I am not
>> sure of is whether or not having no VLAN assigned (on the "TRUNK"
>> network) accomplishes the same this as the "VLAN ID 4095" in VMware:
>> will oVirt/KVM just pass the traffic through for the VM attached to it
>> to deal with?
Yes. Untagged network passes all ethernet frames to the VM, be them
tagged or not. Inside the VM you can further process them (It's less
clear to me how you intend to do the processing, and how would the
firewall would block offensive traffic from reaching "normal" VMs).
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
5:10 p.m.
On Fri, Jan 10, 2014 at 03:06:28PM +0200, Itamar Heim wrote:
On 01/10/2014 01:32 PM, Dan Kenigsberg wrote:
>On Thu, Jan 09, 2014 at 10:53:25PM +0200, Lior Vernia wrote:
>>Hello Alan,
>>
>>On 09/01/14 10:07, Alan Murrell wrote:
>>>Hello,
>>>
>>>I am evaluating oVirt as a replacement/alternative to VMware deployments
>>>we typically do. I have installed and all-in-one setup on a test box
>>>(which itself used to be an ESXi server), but it only has one NIC. I
>>>trying to duplicate our typical configuration we do in VMware, which is
>>>this:
>>>
>>> 1.) we create several "port groups" on the vSwitch, each
assigned a
>>>VLAN ID, such as:
>>>
>>> - VLAN001 (VLAN ID: 1)
>>> - VLAN002 (VLAN ID: 2)
>>> - VLAN009 (VLAN ID: 9)
>>> - VLAN010 (VLAN ID: 10)
>>> - VLAN200 (VLAN ID: 200)
>>> - TRUNK (VLAN ID: 4095 - in VMware-world, VLAN ID "4095" is
"all
>>>VLANS" and basically just passes the VLANs through to whatever is
>>>attached to the port group for the VM to handle)
>>>
>>> 2.) We assign VMs to port groups appropriate for the VLAN they are
>>>part of.
>>> 3.) The only VM that has a NIC assigned to the "TRUNK" port
group is
>>>the firewall (which is Linux), and we create VLAN interfaces on it
>>>(i.e., "eth1.1", "eth1.2", "eth1.10",
"eth1.200"). The firewall VM acts
>>>as the router between the various VLANs.
>>>
>>>To replicate the above in oVirt, I created logical networks for each
>>>VLAN, and assigned the appropriate VLAN ID. It seems oVirt/KVM does not
>>>have an equivalent for VMware's VLAN ID of "4095", so after
some
>>>searching around, so for the "TRUNK" network, I left it with no
VLAN
>>>assigned. Because i cannot add VLAN and non-VLAN networks to the same
>>>physical NIC, after some searching around, it looks like I may have to
>>>utilise two NICS: one for the VLAN networks and one for the "TRUNK"
network.
>>
>>That is true. One non-VLAN network can in fact sit on the same NIC with
>>VLAN networks, but it has to be non-VM.
>
>This was devised as a security constraint - otherwise, a VM attached to
>the non-VLAN network could sniff traffic from another (VLAN) network.
>However, it seems that this is exactly what you need - a special VM that
>is designed to do just that.
>
isn't that was promiscious mode (aka port mirroring) is for?
Oh that makes more sense...
But unfortunately, it is impossible to mirror more than a single network
onto a vnic. (Engine implementation limitation).
However, one can device a tc-based after_network_setup hook, that
directs all traffic from all bridges onto a specific target bridge, onto
which the firewall VM is connected.
Dan.
1:34 a.m.
Quoting "Dan Kenigsberg" <danken(a)redhat.com>:
This was devised as a security constraint - otherwise, a VM attached
to
the non-VLAN network could sniff traffic from another (VLAN) network.
However, it seems that this is exactly what you need - a special VM that
is designed to do just that.
Well, I would prefer it not be a VM but part of the oVirt networking
stack itself. VMware has this built in with just a few clicks (you
assign a VLAN ID of "4095" to a port group/network and it is basically
tagging that port group with all VLAN IDs). VMware of course is not
using the Linux networking, though; they use their own "vSwitch", so
that is probably how they are able to do it.
So it seems to me the problem of no being able to do exactly what I am
looking to do within oVirt itself is not really a shortfall of oVirt,
per se, but the underlying platform on which it relies :-(
And it's not only you: there's another recent request for
lifting this
limitation:
Bug 1049476 - [RFE] Mix untagged and tagged Logical Networks on the
same NIC
I actually do not have a problem with not being able to mix untagged
and tagged Logical Networks on the same NIC; it is very convenient to
be able to do so, but would not be considered a show-stopper IMO; if
two physical NICs would need to be used, so be it.
I do not understand what you are trying to do with dummy devices
(after
all, they are not going to send any packet anywhere).
Since my test server only has one physical NIC, I am using the dummy
devices instead of physical ones. I know they cannot pass traffic
outside of the server (unless attached to a VM was is also attached to
the physical NIC), but I am not concerned with that at the moment. I
am trying to test with a virtual lab, and as long as the
traffic/access behaves as expected within it, there should be no
reason it should not behave as expected with physical NICs, when I get
to that stage.
But if you are willing to mess with network configuration under the
feet
of oVirt, you could do the following:
As long as it does not involve too much complexity, I have no problem
with having to mess with some configuration outside of oVirt. It has
to be kept pretty minimal.
We are looking for a good alternative to VMware so we don't have to
keep putting up with their onerous licensing. oVirt is our
evaluation; if it ticks all our boxes, we would likely go with RHEV
for those clients who are more comfortable with the commercial
support, and oVirt for the others. Unfortunately, this "trunk"
capability is a pretty big one :-(
- create a network tagged with an id that is not really used in your
datacenter, say 999, and attach it to the host.
- build and install vdsm-hook-extnet rpm
- define a vnic profile using this network, and adding a custom propery
called "extnet" with the value of (say) "untagged".
- set up a bridge named "untagged" directly on top of your eth0 (say
"breth0")
- define a libvirt bridged network named "untagged", that uses
"breth0".
- attach the vnic of your firewall VM to your vnic profile.
I will give the above a try and let you know. It might be a few days
before I can get to it though. I am really looking to do a "trunk"
port though, which actually carries multiple tagged VLANs. Going back
to VMware, just for clarification, when VLAN ID "4095" is assigned to
the "trunk" port group/network we create, that's the same thing as
tagging that port group with all VLAN IDs, from "1" through to "4094".
It is very different from having it "untagged".
OpenvSwitch supports this, but it appears it will be a while until
full/natural integration is done with OpenvSwitch. Unfortunately, we
are not developers, so we are unable help with it's integration :-(
Anyway, we are not ready to give up yet. We'll see what we can do
with the above and let you know. The other work-around, of course, is
an earlier suggestion of just adding as many vNICs to the firewall VM
as we need for each VLAN'd Logical Network, but that would raise
another "problem", albeit a rare one: if we were to put oVirt/RHEV in
our own datacenter, replacing VMware, we have a couple of BGP routers
that are setup with a few dozen VLANs. It would be a PITA to add a
vNIC for each one :-( Most of our deployments with our clients,
though, have less than ten VLANs, so it *could* be workable enough in
those cases.
-Alan
6:35 p.m.
------=_Part_25620_10997000.1389407705915
Content-Type: text/plain; charset=GBK
Content-Transfer-Encoding: base64
CmhpLEFsYW4KaSAgdGhpbmsgdGhlIGJlc3Qgd2F5IHRvIHNvbHZlIHlvdXIgcXVlc3Rpb24gaXMg
b3BlbnZzd2l0Y2goY29ycmVzcG9uZGluZyB0byB2bXdhcmUgdnN3aXRjaCkuICBidXQgaXQgaGFz
IG5vdCBiZWVuIGludGlncmF0ZWQgd2l0aCBvdmlydC4KeW91ciAgc29sdXRpb24gYnkgYWRkaW5n
IGR1bW15IGV0aGVybmV0LCAgaSBkbyBub3QgdGhpbmsgaXQgY2FuIHdvcmsgYXMgeW91IGV4cGVj
dC4KYmVjYXVzZSAgdm0ncyBldGhlcm5ldCh2bmV0KSAgaXMgdmxhbi1hd2FyZSBvciBub3QuICAg
aWYgaXQgaXMgdmxhbi1hd2FyZSAsIGl0IGNhbiBiZSBhd2FyZSBvZiBqdXN0IG9ubHkgb25lIHRh
Zy4KcHJvc21pc2MgbW9kZSAgaXMgbGltaXRlZCBpbiBzaW5nbGUgdmxhbiBzY29wZS4gCgoKCgoK
QXQgMjAxNC0wMS0wOSAxNjowNzo0NiwiQWxhbiBNdXJyZWxsIiA8bGlzdHNAbXVycmVsbC5jYT4g
d3JvdGU6CgoKSGVsbG8sCgpJIGFtIGV2YWx1YXRpbmcgb1ZpcnQgYXMgYSByZXBsYWNlbWVudC9h
bHRlcm5hdGl2ZSB0byBWTXdhcmUgZGVwbG95bWVudHMgd2UgdHlwaWNhbGx5IGRvLiAgSSBoYXZl
IGluc3RhbGxlZCBhbmQgYWxsLWluLW9uZSBzZXR1cCBvbiBhIHRlc3QgYm94ICh3aGljaCBpdHNl
bGYgdXNlZCB0byBiZSBhbiBFU1hpIHNlcnZlciksIGJ1dCBpdCBvbmx5IGhhcyBvbmUgTklDLiAg
SSB0cnlpbmcgdG8gZHVwbGljYXRlIG91ciB0eXBpY2FsIGNvbmZpZ3VyYXRpb24gd2UgZG8gaW4g
Vk13YXJlLCB3aGljaCBpcyB0aGlzOgoKICAxLikgd2UgY3JlYXRlIHNldmVyYWwgInBvcnQgZ3Jv
dXBzIiBvbiB0aGUgdlN3aXRjaCwgZWFjaCBhc3NpZ25lZCBhIFZMQU4gSUQsIHN1Y2ggYXM6Cgog
ICAgICAtIFZMQU4wMDEgKFZMQU4gSUQ6IDEpCiAgICAgIC0gVkxBTjAwMiAoVkxBTiBJRDogMikK
ICAgICAgLSBWTEFOMDA5IChWTEFOIElEOiA5KQogICAgICAtIFZMQU4wMTAgKFZMQU4gSUQ6IDEw
KQogICAgICAtIFZMQU4yMDAgKFZMQU4gSUQ6IDIwMCkKICAgICAgLSBUUlVOSyAoVkxBTiBJRDog
NDA5NSAtIGluIFZNd2FyZS13b3JsZCwgVkxBTiBJRCAiNDA5NSIgaXMgImFsbCBWTEFOUyIgYW5k
IGJhc2ljYWxseSBqdXN0IHBhc3NlcyB0aGUgVkxBTnMgdGhyb3VnaCB0byB3aGF0ZXZlciBpcyBh
dHRhY2hlZCB0byB0aGUgcG9ydCBncm91cCBmb3IgdGhlIFZNIHRvIGhhbmRsZSkKCiAgMi4pIFdl
IGFzc2lnbiBWTXMgdG8gcG9ydCBncm91cHMgYXBwcm9wcmlhdGUgZm9yIHRoZSBWTEFOIHRoZXkg
YXJlIHBhcnQgb2YuCiAgMy4pIFRoZSBvbmx5IFZNIHRoYXQgaGFzIGEgTklDIGFzc2lnbmVkIHRv
IHRoZSAiVFJVTksiIHBvcnQgZ3JvdXAgaXMgdGhlIGZpcmV3YWxsICh3aGljaCBpcyBMaW51eCks
IGFuZCB3ZSBjcmVhdGUgVkxBTiBpbnRlcmZhY2VzIG9uIGl0IChpLmUuLCAiZXRoMS4xIiwgImV0
aDEuMiIsICJldGgxLjEwIiwgImV0aDEuMjAwIikuICBUaGUgZmlyZXdhbGwgVk0gYWN0cyBhcyB0
aGUgcm91dGVyIGJldHdlZW4gdGhlIHZhcmlvdXMgVkxBTnMuCgpUbyByZXBsaWNhdGUgdGhlIGFi
b3ZlIGluIG9WaXJ0LCBJIGNyZWF0ZWQgbG9naWNhbCBuZXR3b3JrcyBmb3IgZWFjaCBWTEFOLCBh
bmQgYXNzaWduZWQgdGhlIGFwcHJvcHJpYXRlIFZMQU4gSUQuICBJdCBzZWVtcyBvVmlydC9LVk0g
ZG9lcyBub3QgaGF2ZSBhbiBlcXVpdmFsZW50IGZvciBWTXdhcmUncyBWTEFOIElEIG9mICI0MDk1
Iiwgc28gYWZ0ZXIgc29tZSBzZWFyY2hpbmcgYXJvdW5kLCBzbyBmb3IgdGhlICJUUlVOSyIgbmV0
d29yaywgSSBsZWZ0IGl0IHdpdGggbm8gVkxBTiBhc3NpZ25lZC4gIEJlY2F1c2UgaSBjYW5ub3Qg
YWRkIFZMQU4gYW5kIG5vbi1WTEFOIG5ldHdvcmtzIHRvIHRoZSBzYW1lIHBoeXNpY2FsIE5JQywg
YWZ0ZXIgc29tZSBzZWFyY2hpbmcgYXJvdW5kLCBpdCBsb29rcyBsaWtlIEkgbWF5IGhhdmUgdG8g
dXRpbGlzZSB0d28gTklDUzogb25lIGZvciB0aGUgVkxBTiBuZXR3b3JrcyBhbmQgb25lIGZvciB0
aGUgIlRSVU5LIiBuZXR3b3JrLgoKQmVjYXVzZSwgYXQgdGhpcyBwb2ludCwgSSBhbSBub3QgeWV0
IGNvbmNlcm5lZCB3aXRoIG1ha2luZyB0aGUgdGVzdCBWTXMgSSB3aWxsIGJlIHNldHRpbmcgdXAg
YmUgYWNjZXNzaWJsZSBmcm9tIG91dHNpZGUgdGhlIHZpcnR1YWwgbGFiIGVudmlyb25tZW50IChp
LmUuLCBldmVyeXRoaW5nIHdpbGwgY29tbXVuaWNhdGUgd2l0aGluIG15IG9WaXJ0IHNlcnZlci9u
ZXR3b3JrIGZvciBub3cpLCBJIGFtIHRyeWluZyB0byBtYWtlIHVzZSBvZiAiZHVtbXkiIGludGVy
ZmFjZXMsIGJ1dCBJIGFtIG5vdCBzdXJlIHRoZSBiZXN0IHdheSB0byBtYWtlIHVzZSBvZiB0aGlz
LiAgSSBhbSBhYmxlIHRvIGNyZWF0ZSB0aGUgZHVtbXkqIGludGVyZmFjZXMgYW5kIGhhdmUgdGhl
bSBzaG93IHVwIGluIG9WaXJ0LCBidXQgSSBhbSBub3Qgc3VyZSBvZiBob3cgdGhleSBzaG91bGQg
YmUgc2V0dXAuICBIZXJlIGlzIHdoYXQgSSBhbSAqdGhpbmtpbmcqIHNob3VsZCBiZSBkb25lLCBi
dXQgd2FudCB0byBtYWtlIHN1cmUgaXQgaXMgY29ycmVjdCBiZWZvcmUgZ2V0dGluZyB0b28gZGVl
cDoKCiAgLSBJIHdpbGwgdXNlIHRoZSBwaHlzaWNhbCBOSUMgZm9yIG1hbmFnZW1lbnQsIHRoZXJl
Zm9yZSB0aGUgIm92aXJ0bWdtdCIgYnJpZGdlIHdpdGggZXRoMCBhc3NpZ25lZCB0byBpdCB3aWxs
IHJlbWFpbiBhcy1pcwogIC0gQ3JlYXRlIHR3byBkdW1teSBpbnRlcmZhY2VzOiAiZHVtbXkwIiBh
bmQgImR1bW15MSIKICAtIENyZWF0ZSBhIG5ldyBicmlkZ2UsICJvdmlydHZtIiBhbmQgYXNzaWdu
ICJkdW1teTAiIGFuZCAiZHVtbXkxIiB0byBpdAogIC0gQXR0YWNoIHRoZSBWTEFOLWVuYWJsZWQg
bmV0d29ya3MgdG8gImR1bW15MCIKICAtIEF0dGFjaCB0aGUgIlRSVU5LIiBuZXR3b3JrIHRvICJk
dW1teTEiCgpXb3VsZCB0aGUgYWJvdmUgYmUgdGhlIHdheSB0byBnbyBhYm91dCB0aGlzPyAgVGhl
IG9uZSB0aGluZyBJIGFtIG5vdCBzdXJlIG9mIGlzIHdoZXRoZXIgb3Igbm90IGhhdmluZyBubyBW
TEFOIGFzc2lnbmVkIChvbiB0aGUgIlRSVU5LIiBuZXR3b3JrKSBhY2NvbXBsaXNoZXMgdGhlIHNh
bWUgdGhpcyBhcyB0aGUgIlZMQU4gSUQgNDA5NSIgaW4gVk13YXJlOiB3aWxsIG9WaXJ0L0tWTSBq
dXN0IHBhc3MgdGhlIHRyYWZmaWMgdGhyb3VnaCBmb3IgdGhlIFZNIGF0dGFjaGVkIHRvIGl0IHRv
IGRlYWwgd2l0aD8KClRoYW5rcyBmb3IgcmVhZGluZyB0aGlzIGZhciwgYW5kIEkgYXBwcmVjaWF0
ZSBhbnkgaGVscCB5b3UgbWlnaHQgYmUgYWJsZSB0byBsZW5kIGluIHRoZSBhYm92ZS4KCi1BbGFu
Cg==
------=_Part_25620_10997000.1389407705915
Content-Type: text/html; charset=GBK
Content-Transfer-Encoding: base64
PGRpdiBzdHlsZT0ibGluZS1oZWlnaHQ6MS43O2NvbG9yOiMwMDAwMDA7Zm9udC1zaXplOjE0cHg7
Zm9udC1mYW1pbHk6YXJpYWwiPjxicj5oaSxBbGFuPGRpdj5pICZuYnNwO3RoaW5rIHRoZSBiZXN0
IHdheSB0byBzb2x2ZSB5b3VyIHF1ZXN0aW9uIGlzIG9wZW52c3dpdGNoKGNvcnJlc3BvbmRpbmcg
dG8gdm13YXJlIHZzd2l0Y2gpLiAmbmJzcDtidXQgaXQgaGFzIG5vdCBiZWVuIGludGlncmF0ZWQg
d2l0aCBvdmlydC48L2Rpdj48ZGl2PnlvdXIgJm5ic3A7c29sdXRpb24gYnkgYWRkaW5nIGR1bW15
IGV0aGVybmV0LCAmbmJzcDtpIGRvIG5vdCB0aGluayBpdCBjYW4gd29yayBhcyB5b3UgZXhwZWN0
LjwvZGl2PjxkaXY+YmVjYXVzZSAmbmJzcDt2bSdzIGV0aGVybmV0KHZuZXQpICZuYnNwO2lzIHZs
YW4tYXdhcmUgb3Igbm90LiAmbmJzcDsgaWYgaXQgaXMgdmxhbi1hd2FyZSAsIGl0IGNhbiBiZSBh
d2FyZSBvZiBqdXN0IG9ubHkgb25lIHRhZy48L2Rpdj48ZGl2PnByb3NtaXNjIG1vZGUgJm5ic3A7
aXMgbGltaXRlZCBpbiBzaW5nbGUgdmxhbiBzY29wZS4mbmJzcDs8YnI+PGJyPjxicj48YnI+PGRp
dj48L2Rpdj48ZGl2IGlkPSJkaXZOZXRlYXNlTWFpbENhcmQiPjwvZGl2Pjxicj5BdCAyMDE0LTAx
LTA5IDE2OjA3OjQ2LCJBbGFuJm5ic3A7TXVycmVsbCImbmJzcDsmbHQ7bGlzdHNAbXVycmVsbC5j
YSZndDsgd3JvdGU6PGJyPiA8YmxvY2txdW90ZSBpZD0iaXNSZXBseUNvbnRlbnQiIHN0eWxlPSJQ
QURESU5HLUxFRlQ6IDFleDsgTUFSR0lOOiAwcHggMHB4IDBweCAwLjhleDsgQk9SREVSLUxFRlQ6
ICNjY2MgMXB4IHNvbGlkIj4KCgoKCgoKCgo8cD48Zm9udCBzaXplPSIyIj5IZWxsbyw8YnI+Cjxi
cj4KSSBhbSBldmFsdWF0aW5nIG9WaXJ0IGFzIGEgcmVwbGFjZW1lbnQvYWx0ZXJuYXRpdmUgdG8g
Vk13YXJlIGRlcGxveW1lbnRzIHdlIHR5cGljYWxseSBkby4mbmJzcDsgSSBoYXZlIGluc3RhbGxl
ZCBhbmQgYWxsLWluLW9uZSBzZXR1cCBvbiBhIHRlc3QgYm94ICh3aGljaCBpdHNlbGYgdXNlZCB0
byBiZSBhbiBFU1hpIHNlcnZlciksIGJ1dCBpdCBvbmx5IGhhcyBvbmUgTklDLiZuYnNwOyBJIHRy
eWluZyB0byBkdXBsaWNhdGUgb3VyIHR5cGljYWwgY29uZmlndXJhdGlvbiB3ZSBkbyBpbiBWTXdh
cmUsIHdoaWNoIGlzIHRoaXM6PGJyPgo8YnI+CiZuYnNwOyAxLikgd2UgY3JlYXRlIHNldmVyYWwg
InBvcnQgZ3JvdXBzIiBvbiB0aGUgdlN3aXRjaCwgZWFjaCBhc3NpZ25lZCBhIFZMQU4gSUQsIHN1
Y2ggYXM6PGJyPgo8YnI+CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtIFZMQU4wMDEg
KFZMQU4gSUQ6IDEpPGJyPgombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLSBWTEFOMDAy
IChWTEFOIElEOiAyKTxicj4KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0gVkxBTjAw
OSAoVkxBTiBJRDogOSk8YnI+CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtIFZMQU4w
MTAgKFZMQU4gSUQ6IDEwKTxicj4KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0gVkxB
TjIwMCAoVkxBTiBJRDogMjAwKTxicj4KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0g
VFJVTksgKFZMQU4gSUQ6IDQwOTUgLSBpbiBWTXdhcmUtd29ybGQsIFZMQU4gSUQgIjQwOTUiIGlz
ICJhbGwgVkxBTlMiIGFuZCBiYXNpY2FsbHkganVzdCBwYXNzZXMgdGhlIFZMQU5zIHRocm91Z2gg
dG8gd2hhdGV2ZXIgaXMgYXR0YWNoZWQgdG8gdGhlIHBvcnQgZ3JvdXAgZm9yIHRoZSBWTSB0byBo
YW5kbGUpPGJyPgo8YnI+CiZuYnNwOyAyLikgV2UgYXNzaWduIFZNcyB0byBwb3J0IGdyb3VwcyBh
cHByb3ByaWF0ZSBmb3IgdGhlIFZMQU4gdGhleSBhcmUgcGFydCBvZi48YnI+CiZuYnNwOyAzLikg
VGhlIG9ubHkgVk0gdGhhdCBoYXMgYSBOSUMgYXNzaWduZWQgdG8gdGhlICJUUlVOSyIgcG9ydCBn
cm91cCBpcyB0aGUgZmlyZXdhbGwgKHdoaWNoIGlzIExpbnV4KSwgYW5kIHdlIGNyZWF0ZSBWTEFO
IGludGVyZmFjZXMgb24gaXQgKGkuZS4sICJldGgxLjEiLCAiZXRoMS4yIiwgImV0aDEuMTAiLCAi
ZXRoMS4yMDAiKS4mbmJzcDsgVGhlIGZpcmV3YWxsIFZNIGFjdHMgYXMgdGhlIHJvdXRlciBiZXR3
ZWVuIHRoZSB2YXJpb3VzIFZMQU5zLjxicj4KPGJyPgpUbyByZXBsaWNhdGUgdGhlIGFib3ZlIGlu
IG9WaXJ0LCBJIGNyZWF0ZWQgbG9naWNhbCBuZXR3b3JrcyBmb3IgZWFjaCBWTEFOLCBhbmQgYXNz
aWduZWQgdGhlIGFwcHJvcHJpYXRlIFZMQU4gSUQuJm5ic3A7IEl0IHNlZW1zIG9WaXJ0L0tWTSBk
b2VzIG5vdCBoYXZlIGFuIGVxdWl2YWxlbnQgZm9yIFZNd2FyZSdzIFZMQU4gSUQgb2YgIjQwOTUi
LCBzbyBhZnRlciBzb21lIHNlYXJjaGluZyBhcm91bmQsIHNvIGZvciB0aGUgIlRSVU5LIiBuZXR3
b3JrLCBJIGxlZnQgaXQgd2l0aCBubyBWTEFOIGFzc2lnbmVkLiZuYnNwOyBCZWNhdXNlIGkgY2Fu
bm90IGFkZCBWTEFOIGFuZCBub24tVkxBTiBuZXR3b3JrcyB0byB0aGUgc2FtZSBwaHlzaWNhbCBO
SUMsIGFmdGVyIHNvbWUgc2VhcmNoaW5nIGFyb3VuZCwgaXQgbG9va3MgbGlrZSBJIG1heSBoYXZl
IHRvIHV0aWxpc2UgdHdvIE5JQ1M6IG9uZSBmb3IgdGhlIFZMQU4gbmV0d29ya3MgYW5kIG9uZSBm
b3IgdGhlICJUUlVOSyIgbmV0d29yay48YnI+Cjxicj4KQmVjYXVzZSwgYXQgdGhpcyBwb2ludCwg
SSBhbSBub3QgeWV0IGNvbmNlcm5lZCB3aXRoIG1ha2luZyB0aGUgdGVzdCBWTXMgSSB3aWxsIGJl
IHNldHRpbmcgdXAgYmUgYWNjZXNzaWJsZSBmcm9tIG91dHNpZGUgdGhlIHZpcnR1YWwgbGFiIGVu
dmlyb25tZW50IChpLmUuLCBldmVyeXRoaW5nIHdpbGwgY29tbXVuaWNhdGUgd2l0aGluIG15IG9W
aXJ0IHNlcnZlci9uZXR3b3JrIGZvciBub3cpLCBJIGFtIHRyeWluZyB0byBtYWtlIHVzZSBvZiAi
ZHVtbXkiIGludGVyZmFjZXMsIGJ1dCBJIGFtIG5vdCBzdXJlIHRoZSBiZXN0IHdheSB0byBtYWtl
IHVzZSBvZiB0aGlzLiZuYnNwOyBJIGFtIGFibGUgdG8gY3JlYXRlIHRoZSBkdW1teSogaW50ZXJm
YWNlcyBhbmQgaGF2ZSB0aGVtIHNob3cgdXAgaW4gb1ZpcnQsIGJ1dCBJIGFtIG5vdCBzdXJlIG9m
IGhvdyB0aGV5IHNob3VsZCBiZSBzZXR1cC4mbmJzcDsgSGVyZSBpcyB3aGF0IEkgYW0gKnRoaW5r
aW5nKiBzaG91bGQgYmUgZG9uZSwgYnV0IHdhbnQgdG8gbWFrZSBzdXJlIGl0IGlzIGNvcnJlY3Qg
YmVmb3JlIGdldHRpbmcgdG9vIGRlZXA6PGJyPgo8YnI+CiZuYnNwOyAtIEkgd2lsbCB1c2UgdGhl
IHBoeXNpY2FsIE5JQyBmb3IgbWFuYWdlbWVudCwgdGhlcmVmb3JlIHRoZSAib3ZpcnRtZ210IiBi
cmlkZ2Ugd2l0aCBldGgwIGFzc2lnbmVkIHRvIGl0IHdpbGwgcmVtYWluIGFzLWlzPGJyPgombmJz
cDsgLSBDcmVhdGUgdHdvIGR1bW15IGludGVyZmFjZXM6ICJkdW1teTAiIGFuZCAiZHVtbXkxIjxi
cj4KJm5ic3A7IC0gQ3JlYXRlIGEgbmV3IGJyaWRnZSwgIm92aXJ0dm0iIGFuZCBhc3NpZ24gImR1
bW15MCIgYW5kICJkdW1teTEiIHRvIGl0PGJyPgombmJzcDsgLSBBdHRhY2ggdGhlIFZMQU4tZW5h
YmxlZCBuZXR3b3JrcyB0byAiZHVtbXkwIjxicj4KJm5ic3A7IC0gQXR0YWNoIHRoZSAiVFJVTksi
IG5ldHdvcmsgdG8gImR1bW15MSI8YnI+Cjxicj4KV291bGQgdGhlIGFib3ZlIGJlIHRoZSB3YXkg
dG8gZ28gYWJvdXQgdGhpcz8mbmJzcDsgVGhlIG9uZSB0aGluZyBJIGFtIG5vdCBzdXJlIG9mIGlz
IHdoZXRoZXIgb3Igbm90IGhhdmluZyBubyBWTEFOIGFzc2lnbmVkIChvbiB0aGUgIlRSVU5LIiBu
ZXR3b3JrKSBhY2NvbXBsaXNoZXMgdGhlIHNhbWUgdGhpcyBhcyB0aGUgIlZMQU4gSUQgNDA5NSIg
aW4gVk13YXJlOiB3aWxsIG9WaXJ0L0tWTSBqdXN0IHBhc3MgdGhlIHRyYWZmaWMgdGhyb3VnaCBm
b3IgdGhlIFZNIGF0dGFjaGVkIHRvIGl0IHRvIGRlYWwgd2l0aD88YnI+Cjxicj4KVGhhbmtzIGZv
ciByZWFkaW5nIHRoaXMgZmFyLCBhbmQgSSBhcHByZWNpYXRlIGFueSBoZWxwIHlvdSBtaWdodCBi
ZSBhYmxlIHRvIGxlbmQgaW4gdGhlIGFib3ZlLjxicj4KPGJyPgotQWxhbjxicj4KPC9mb250Pgo8
L3A+CgoKPC9ibG9ja3F1b3RlPjwvZGl2PjwvZGl2Pjxicj48YnI+PHNwYW4gdGl0bGU9Im5ldGVh
c2Vmb290ZXIiPjxzcGFuIGlkPSJuZXRlYXNlX21haWxfZm9vdGVyIj48L3NwYW4+PC9zcGFuPg==
------=_Part_25620_10997000.1389407705915--
5:07 a.m.
New subject: [Users] [SOLVED] Re: Networking questions (LONG)
I just thought I would reply back to my own thread with what my team
and I have come up with. While I have marked this as "Solved", don't
get too excited; it is not exactly the resolution we were looking for,
but is acceptable nonetheless.
After some further digging around, we found that it is possible to
pass hardware (including a NIC) through to a guest. Unfortunately,
this renders the guest unable to be migrated to another host
automatically.
In a single-server setup (which many of our clients' setups are via
VMware, currently0, this would not make a difference, since there is
no other host to migrate to anyway. Son in those cases, not much
changes.
For multi-server setups, we have two choices:
1.) Forgo the virtual firewall and purchase a "Lanner" or similar
hardware to install the firewall onto. Since a multi-server setup (at
least two server + SAN) typically runs a minimum of $10K-$15K in
hardware alone, an addition $300 or so for the "Lanner" (or similar
hardware) would not increase the overall cost of the project in a
significant way. (This option could of course be used in a
single-server setup as well, but hardware cost is usually more of a
factor with these setups for our clients)
2.) Setup a firewall guest on two of the hosts, and configure them
in an active-passive fashion. As long as both of the hosts with the
firewall VMs do not go down at the same time, then there should not be
an issue. If a host with a firewall VM goes down, the other firewall
VM will take over.
So, those are the "work-arounds" that we have come up with (nothing
new to anyone here, I am sure) until such time as "OpenVSwitch" gets
adopted into oVirt/RHEV as either an easy-to-enable option, or as the
standard/default switch.
Anyway, this post was really more of a "closure" post so anyone coming
across this thread in the future does not wonder what the ultimate
outcome was. :-)
-Alan
5 p.m.
New subject: [Users] [SOLVED] Re: Networking questions (LONG)
Hi Alan,
May I just inquire about the two alternative solutions that had been
proposed here, and why you opted against? As a reminder, I'm referring to:
1. Using a firewall VM with one vNIC per VLAN network.
2. Using VDMS hooks to simulate TRUNK.
Both of these should allow migration, etc. without any additional
procurement, and require only the one firewall VM. Are the "Lanner" and
dual-firewall solutions simpler?
Yours, Lior.
On 21/01/14 05:07, Alan Murrell wrote:
I just thought I would reply back to my own thread with what my team
and
I have come up with. While I have marked this as "Solved", don't get
too excited; it is not exactly the resolution we were looking for, but
is acceptable nonetheless.
After some further digging around, we found that it is possible to pass
hardware (including a NIC) through to a guest. Unfortunately, this
renders the guest unable to be migrated to another host automatically.
In a single-server setup (which many of our clients' setups are via
VMware, currently0, this would not make a difference, since there is no
other host to migrate to anyway. Son in those cases, not much changes.
For multi-server setups, we have two choices:
1.) Forgo the virtual firewall and purchase a "Lanner" or similar
hardware to install the firewall onto. Since a multi-server setup (at
least two server + SAN) typically runs a minimum of $10K-$15K in
hardware alone, an addition $300 or so for the "Lanner" (or similar
hardware) would not increase the overall cost of the project in a
significant way. (This option could of course be used in a
single-server setup as well, but hardware cost is usually more of a
factor with these setups for our clients)
2.) Setup a firewall guest on two of the hosts, and configure them in
an active-passive fashion. As long as both of the hosts with the
firewall VMs do not go down at the same time, then there should not be
an issue. If a host with a firewall VM goes down, the other firewall VM
will take over.
So, those are the "work-arounds" that we have come up with (nothing new
to anyone here, I am sure) until such time as "OpenVSwitch" gets adopted
into oVirt/RHEV as either an easy-to-enable option, or as the
standard/default switch.
Anyway, this post was really more of a "closure" post so anyone coming
across this thread in the future does not wonder what the ultimate
outcome was. :-)
-Alan
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
3959
days inactive
3971
days old
14 comments
7 participants
participants (7)
-
Alan Murrell -
bigclouds -
Dan Kenigsberg -
Itamar Heim -
Juan Pablo Lorier -
Lior Vernia -
Sven Kieske