Bug 704407

Summary:	DHCP range value will not refresh if re-fill in the IPv4 address when creating a new virtual network
Product:	[Community] Virtualization Tools	Reporter:	Min Zhan <mzhan>
Component:	virt-manager	Assignee:	Cole Robinson <crobinso>
Status:	CLOSED UPSTREAM	QA Contact:
Severity:	low	Docs Contact:
Priority:	low
Version:	unspecified	CC:	berrange, crobinso, dyuan, llim, mshao, mzhan, xen-maint
Target Milestone:	---
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2013-09-28 22:26:06 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description Min Zhan 2011-05-13 03:38:42 UTC

Description of problem:
When create a new virtual network, fill in IPv4 address, forward until the last step, Then click Back to re-fill in IPv4 address, click next, but DHCP range value is still no change

Version-Release number of selected component (if applicable):
virt-manager-0.6.1-14.el5

How reproducible:
Always

Steps to Reproduce:
1. Create a new virtual network, fill in IPv4 address, next, until the last step
2. In last step click Back, Back to re-fill in the IPv4 address
3. Click Next, check DHCP range value
  
Actual results:
The first time fill in IPv4 address, the DHCP range will change correspondingly. But Back to re-fill in IPv4 address, the DHCP range will keep as the first time

Expected results:
DHCP range should change correspondingly once IPv4 address is changed.

Additional info:

Comment 1 RHEL Program Management 2011-06-20 22:50:47 UTC

This request was evaluated by Red Hat Product Management for inclusion in Red Hat Enterprise Linux 5.7 and Red Hat does not plan to fix this issue the currently developed update.

Contact your manager or support representative in case you need to escalate this bug.

Comment 3 Cole Robinson 2011-07-13 00:48:26 UTC

Since this is low impact, it's not worth fixing in the lifetime of RHEL5. Moving to upstream tracker since it is still present upstream.

Comment 4 Cole Robinson 2013-09-28 22:26:06 UTC

This should be fixed upstream nowadays