[Users] Networking questions (LONG)
------_=_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--
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
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
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@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Hello Lior, Thank you for your reply. Quoting "Lior Vernia" <lvernia@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
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@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
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).
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:
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
On Thu, Jan 09, 2014 at 10:53:25PM +0200, Lior Vernia wrote: 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).
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.
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@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
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.
Quoting "Dan Kenigsberg" <danken@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
------=_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--
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
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@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
participants (7)
-
Alan Murrell -
bigclouds -
Dan Kenigsberg -
Itamar Heim -
Juan Pablo Lorier -
Lior Vernia -
Sven Kieske