Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
I check this issue in RHEL7.0 release version and the newest hypervkvpd also have the issue, so clone it.
hyperkvpd-version:
hypervkvpd-0-0.18.20130826git.el7.x86_64
+++ This bug was initially created as a clone of Bug #1122865 +++
Description of problem:
Execute kvp-ip-injection.ps1, The IP inject in Ethernet not bridge network
The script will change ethernet (Such as eht1) to static IP, not it's bridge network adapter
# ip addr
...
2: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
link/ether 00:15:5d:6a:49:1a brd ff:ff:ff:ff:ff:ff
inet 10.200.48.155/22 brd 10.200.51.255 scope global eth1
inet6 fe80::215:5dff:fe6a:491a/64 scope link
valid_lft forever preferred_lft forever
3: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
link/ether 00:15:5d:6a:49:1a brd ff:ff:ff:ff:ff:ff
inet 10.66.109.142/21 brd 10.66.111.255 scope global br0
inet6 fe80::215:5dff:fe6a:491a/64 scope link
valid_lft forever preferred_lft forever
...
# brctl show
bridge name bridge id STP enabled interfaces
br0 8000.00155d6a491a no eth1
virbr0 8000.5254000d723b yes virbr0-nic
Version-Release number of selected component (if applicable):
Host: Hyper-V Server 2012 R2
kernel version:
2.6.32-491.el6
hypervkvpd-0-0.15.20130826git.el6.x86_64
How reproducible:
100%
Steps to Reproduce:
1. Login RHEL and Bridge Ethernet (such as eth0)
2. Install and start hypervkvpd
3. Execute kvp-ip-injection.ps1 in Host
Actual Result:
IP inject Ethernet eth0 not br0
Expected Result:
The IP injection should change br0 IP if guest have bridge network but it's bond ethernet adpater
Additional info:
--- Additional comment from dnie on 2014-07-24 05:02:59 EDT ---
IP injection scripts
--- Additional comment from RHEL Product and Program Management on 2014-07-24 05:11:36 EDT ---
Since this bug report was entered in bugzilla, the release flag has been
set to ? to ensure that it is properly evaluated for this release.
I don't think we're seeing a bug here (or at least not a bug we can easily fix). It is rather a design issue with hyperv-kvpd. Hyper-V host has no idea about complex network configuration you have in your guest. It can be really complex in case you use bridging, bonding, ... hyperv-kvpd uses MAC address of a network card as an identifier when communicates with guest (both 'get' and 'set' requests) so it will always be changing real network adapter's address no matter what you've stacked on top.
I don't see an easy way to change anything here. Right now only simple configurations (network card with 1 static or dhcp address) are supported.
(In reply to Vitaly Kuznetsov from comment #1)
> I don't think we're seeing a bug here (or at least not a bug we can easily
> fix). It is rather a design issue with hyperv-kvpd. Hyper-V host has no idea
> about complex network configuration you have in your guest. It can be really
> complex in case you use bridging, bonding, ... hyperv-kvpd uses MAC address
> of a network card as an identifier when communicates with guest (both 'get'
> and 'set' requests) so it will always be changing real network adapter's
> address no matter what you've stacked on top.
>
> I don't see an easy way to change anything here. Right now only simple
> configurations (network card with 1 static or dhcp address) are supported.
Hi Vitaly,
Since it is host design issue, could we close the bug as cantfix/wontfix?
Could i know your opinion?
(In reply to Shengnan Wang from comment #3)
>
> Hi Vitaly,
>
> Since it is host design issue, could we close the bug as cantfix/wontfix?
> Could i know your opinion?
Yes, we can't fix that.