Bug 742047
| Summary: | Ability to add a RHEL host to RHEV with a preconfigured bond | ||
|---|---|---|---|
| Product: | [oVirt] ovirt-host-deploy | Reporter: | John Brier <jbrier> |
| Component: | Plugins.VDSM | Assignee: | Alon Bar-Lev <alonbl> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Martin Pavlik <mpavlik> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | --- | CC: | abaron, alonbl, bazulay, bugs, byount, danken, dougsland, dyasny, emcnabb, iheim, lpeer, mhuth, pep, Rhev-m-bugs, sgrinber, ykaul |
| Target Milestone: | --- | Keywords: | FutureFeature, Improvement |
| Target Release: | 1.0.0 | Flags: | danken:
devel_ack+
|
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | network | ||
| Fixed In Version: | sf2 | Doc Type: | Enhancement |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | Type: | --- | |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | Network | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 761411, 866889 | ||
| Bug Blocks: | 731146 | ||
|
Description
John Brier
2011-09-28 20:51:44 UTC
(In reply to comment #0) > /var/log/vdsm/vdsm.log shows: > > Wed, 28 Sep 2011 15:35:34 DEBUG Bridge rhevm not found, need to create it. That should be /tmp/vds_bootstrap.457582.log === In Red Hat Customer Portal Case 00473041 === --- Comment by Brier, John on 11/17/2011 10:21 AM --- This RFE might not be as important anymore for US Courts.. I was just checking up on the status of this and I was surprised to see the RFE for cobbler has apparently been fulfilled: https://fedorahosted.org/cobbler/ticket/670 == 10/16/11 08:12:01 changed by unbeliever ΒΆ * status changed from new to closed. * state changed from Under review to Released. * version set to 2.1 devel. * resolution set to fixed. this feature is available in cobbler 2.2.x == https://fedorahosted.org/pipermail/cobbler/2011-October/006751.html == Cobbler 2.2 has been tagged and released, with RPMS built and available in EPEL-testing now. This release incorporates a ton of new features: * Import modules, which allowed easy integration of... * Ubuntu and Debian support again! * Better support for SuSE * Support for FreeBSD * Support for ESX 4+/ESXi * Integration with the python TFTP server pytftpd * "fetchable files" and "boot files" support for distros that need to get more files from the TFTP server * Faster sync using link cache * Support for EFI grub booting * Support for bridged interfaces <-------------------------------------------BRIDGE support! * WSGI instead of mod_python for the web interface. * Lots of Web UI improvements * A lot more I'm sure I missed when going through the change log Bugfixes: * Seriously way too many to list individually. Read the change log, there were almost 1000 commits since the last release! This will also start the new development period, in which we will target a major release every 6 months. That means we should release 2.4 in April of 2012, with periodic updates to 2.2.x monthly for bug fixes. February 6th of 2012 will mark the end of the development period for 2.4, after which only bug fixes will be applied to the master branch until 2.4 is released. == I have asked the customer to try this. === In Red Hat Customer Portal Case 00599673 === --- Comment by Yount, Bryan on 3/21/2012 12:32 PM --- +1 for Qualcomm wanting this They have a workaround for now but they want the ability to do this in a future version of RHEV. Perhaps 3.1? The customer commented that he "actually wrote a script that will pre-bond the interfaces, then create the rhevm bridge and migrate the configuration to it. After RHEV installs the host, it uses the existing rhevm bridge without an issue. (If only that would work for the hosts' logical networks!). So while this isn't a super-high priority, it'd be nice to have fixed. Medium is fine." (In reply to comment #3) > === In Red Hat Customer Portal Case 00599673 === > --- Comment by Yount, Bryan on 3/21/2012 12:32 PM --- > > +1 for Qualcomm wanting this > > They have a workaround for now but they want the ability to do this in a future > version of RHEV. Perhaps 3.1? The customer commented that he "actually wrote a > script that will pre-bond the interfaces, then create the rhevm bridge and > migrate the configuration to it. After RHEV installs the host, it uses the > existing rhevm bridge without an issue. (If only that would work for the > hosts' logical networks!). So while this isn't a super-high priority, it'd be > nice to have fixed. Medium is fine." Bryan, this looks like a different issue. In the original BZ the problem is that their cobbler setup enforced them to start up with a bond. Here you are describing how to bond rhevm. So if the problem is bonding rhevm network after initial installation - this is already solved in 3.0.3 (In reply to comment #4) > Bryan, this looks like a different issue. In the original BZ the problem is > that their cobbler setup enforced them to start up with a bond. Here you are > describing how to bond rhevm. So if the problem is bonding rhevm network after > initial installation - this is already solved in 3.0.3 Maybe my description of it was lacking. Basically, here's what Qualcomm just said about it: "This actually was in the event our install process creates the bond0 interface for us - there will be an existing bond0 interface and rhev-m won't create the 'rhevm' bridge on an already bonded adapter." this is not trivial to solve. requesting this will be added to a future PRD in coordination between GSS and PM British Airways (TAM, strategic, segment 1 customer) are also interested on this for the same reasons: all their hosts get provisioned with bonded interfaces. The outlook is that if they finally fully adopt RHEV they will be adding lots of hosts to it, so they'd like the process to be as straightforward as possible. From the original description: > Note this workaround does not work in RHEV 3.0 external beta 2, > When you click "Ok" in the Edit Network Interface dialog you get > > Operation Canceled > rhevh-5.gsslab.rdu.redhat.com > * Specified network doesn't exist This is bug 761411, and once addressed they will hopefully have a reasonable workaround, but still the interest of being able to do this without extra steps remains. *** Bug 531390 has been marked as a duplicate of this bug. *** livnat - what is the gap from the current implementation? is this a network management issue or more of a bootstrap issue? new bootstrap does not support this either. I guess bug#761411 should be validated first. Dan, So can I use addNetwork on bond interface in 3.2? What is the exact syntax? Thanks! Usage:
/usr/share/vdsm/addNetwork bridge {vlan-id|''} {bonding|''} nic[,nic] [option=value]
For example: /usr/share/vdsm/addNetwork ovirtmgmt '' bond0 em1,em2 MTU=9000
commit aef14b90363ebacdba27940ffa6826ba5e1062a5
Author: Alon Bar-Lev <alonbl>
Date: Wed Dec 5 13:25:40 2012 +0200
vdsm: bridge: support bridge over bond interface
Change-Id: Iace6ca78e494811f91b9df94b5312a0518cfcf78
Signed-off-by: Alon Bar-Lev <alonbl>
http://gerrit.ovirt.org/#/c/9741/
NOTE: it will probably fail when trying to deploy vdsm of 3.0, as bug#761411 was not fixed in 3.0.z.
Need to be tested within specific rhev-h/bonding setup. Modified per future rebase for 3.2. Alon, I see an upstream commit, where are we with this downstream? (In reply to comment #16) > Alon, I see an upstream commit, where are we with this downstream? Untested, but should work in 3.2. If someone can provide feedback it would be great, should be trivial to fix any issue. Setting on 3.2 then, feel free to postpone to 3.3 if not feasible (In reply to comment #18) > Setting on 3.2 then, feel free to postpone to 3.3 if not feasible Pushing. We don't add features now. I do wonder how the BZ is in MODIFIED state already, though. (In reply to comment #19) > (In reply to comment #18) > > Setting on 3.2 then, feel free to postpone to 3.3 if not feasible > > Pushing. We don't add features now. > > I do wonder how the BZ is in MODIFIED state already, though. I'm not even sure why this should be a feature and not a bugfix, but lets leave it on 3.3 anyway (In reply to comment #19) > (In reply to comment #18) > > Setting on 3.2 then, feel free to postpone to 3.3 if not feasible > > Pushing. We don't add features now. > > I do wonder how the BZ is in MODIFIED state already, though. Because it already implemented upstream. (In reply to comment #21) > (In reply to comment #19) > > (In reply to comment #18) > > > Setting on 3.2 then, feel free to postpone to 3.3 if not feasible > > > > Pushing. We don't add features now. > > > > I do wonder how the BZ is in MODIFIED state already, though. > > Because it already implemented upstream. Move to POST, then. Unless it was merged upstream before the last rebase. In that case, it should be in ON_QA already. (In reply to comment #22) > (In reply to comment #21) > > (In reply to comment #19) > > > (In reply to comment #18) > > > > Setting on 3.2 then, feel free to postpone to 3.3 if not feasible > > > > > > Pushing. We don't add features now. > > > > > > I do wonder how the BZ is in MODIFIED state already, though. > > > > Because it already implemented upstream. > > Move to POST, then. Unless it was merged upstream before the last rebase. > In that case, it should be in ON_QA already. I think I learned the game ball rules... This is MODIFIED as the ovirt-host-deploy-1.0.0 already contain this. You can ignore it and/or skip testing but it is there. (In reply to comment #20) > I'm not even sure why this should be a feature and not a bugfix, but lets > leave it on 3.3 anyway So are we considering this an RFE or a bugfix now? I want to make sure my ticket is tagged appropriately as I just picked back up Qualcomm now that Kevin Masaryk is no longer with Red Hat. (In reply to comment #24) > (In reply to comment #20) > > I'm not even sure why this should be a feature and not a bugfix, but lets > > leave it on 3.3 anyway > > So are we considering this an RFE or a bugfix now? I want to make sure my > ticket is tagged appropriately as I just picked back up Qualcomm now that > Kevin Masaryk is no longer with Red Hat. Hmmm... I really consider this as bugfix as vdsm should have supported it in the past... there is the cmdline option of addNetwork and such... ovirt-host-deploy side all is setup. if there is an issue with addNetwork of vdsm, please discuss it at bug#761411 in sf13.1 host with preconfigured bond is added properly, rhevm bridge interface is created on top of the bond 3.2 has been released 3.2 has been released 3.2 has been released |