Repository navigation
Conversation
|
@blueorangutan package |
|
@nvazquez a [SL] Jenkins job has been kicked to build packages. It will be bundled with KVM, XenServer and VMware SystemVM templates. I'll keep you posted as I make progress. |
Codecov Report✅ All modified and coverable lines are covered by tests.
Additional details and impacted files@@ Coverage Diff @@
## 4.22 #14333 +/- ##
=============================================
- Coverage 18.02% 4.04% -13.99%
=============================================
Files 5936 449 -5487
Lines 535823 38283 -497540
Branches 65612 7082 -58530
=============================================
- Hits 96582 1547 -95035
+ Misses 428242 36521 -391721
+ Partials 10999 215 -10784
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
|
Packaging result [SF]: ✔️ el8 ✔️ el9 ✔️ el10 ✔️ debian ✔️ suse15. SL-JID 19442 |
|
@blueorangutan test |
|
@nvazquez a [SL] Trillian-Jenkins test job (ol8 mgmt + kvm-ol8) has been kicked to run smoke tests |
There was a problem hiding this comment.
Copilot review overview
🟡 Changes recommended
Legacy APIPA values can remain exposed, and malformed IPv6 zone input can throw unexpectedly.
Review effort: Balanced
Findings: 2
Open (2)
What changed in this PR
Fixes stale APIPA/link-local addresses reported for externally DHCP-managed L2 VM NICs.
Changes:
- Adds IPv4/IPv6 link-local detection utilities.
- Filters link-local addresses from KVM guest-agent results.
- Retries NICs containing previously recorded APIPA addresses.
| File | Description |
|---|---|
NetUtils.java |
Adds link-local address helpers. |
NetUtilsTest.java |
Tests link-local detection. |
UserVmManagerImpl.java |
Handles and retries APIPA NIC addresses. |
LibvirtGetVmIpAddressCommandWrapper.java |
Ignores link-local guest addresses. |
LibvirtGetVmIpAddressCommandWrapperTest.java |
Tests APIPA and DHCP parsing. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
|
[SF] Trillian test result (tid-17089)
|
| nic.setIPv4Address(null); | ||
| _nicDao.update(nicId, nic); | ||
| } | ||
| } else if (NetUtils.isLinkLocalIp4(vmIp)) { |
There was a problem hiding this comment.
on xenserver this still counts as a failed try, so after about 30 min we stop checking and a lease that comes later is never picked up. should this skip the count like kvm does now?
There was a problem hiding this comment.
Warning
Copilot couldn't run its full agentic review because it didn't start before the timeout. Make sure your repository has a runner available, or add a copilot-code-review.yml file specifying one with the runs-on attribute. See the docs for more details.
Copilot review overview
4 open findings
SettingdecrementCount = falseon APIPA can result in effectively unbounded retries if a guest… · New AvoidString.format(...)insidelogger.debug(...)since it formats eagerly even when debug… · New These test fixtures are constants and should be declaredprivate static finalto prevent… · New The ‘clear APIPA and persist’ logic is duplicated with the retry loop earlier in this class.… · New
2 resolved since last review
🧠 Review effort: Lite
| } else if (NetUtils.isLinkLocalIp4(vmIp)) { | ||
| // a link-local (APIPA) address means the guest has not obtained a DHCP lease yet; do not record it, | ||
| // clear any previously recorded link-local address and keep retrying without consuming the retry budget | ||
| // (consistent with KVM, which reports this case as a failed answer), so a late DHCP lease is still picked up | ||
| logger.debug("Instance [ID: {}, UUID: {}, name: {}] - ignoring link-local IP {}, DHCP lease not obtained yet", | ||
| vmId, vmUuid, vmName, vmIp); | ||
| decrementCount = false; | ||
| if (nic != null && NetUtils.isLinkLocalIp4(nic.getIPv4Address())) { | ||
| nic.setIPv4Address(null); | ||
| _nicDao.update(nicId, nic); | ||
| } |
| // Skip link-local addresses (e.g. Windows APIPA 169.254.0.0/16 before a DHCP lease is obtained), | ||
| // they are not routable and must not be reported as the instance IP | ||
| if (ipFamily.equals("ipv4")) { | ||
| ipv4 = ipPart; | ||
| if (NetUtils.isLinkLocalIp4(ipPart)) { | ||
| logger.debug(String.format("Ignoring link-local ipv4 %s with mac address %s", ipPart, macAddress)); | ||
| } else { | ||
| ipv4 = ipPart; | ||
| } | ||
| } else if (ipFamily.equals("ipv6")) { | ||
| ipv6 = ipPart; | ||
| if (NetUtils.isLinkLocalIp6(ipPart)) { | ||
| logger.debug(String.format("Ignoring link-local ipv6 %s with mac address %s", ipPart, macAddress)); | ||
| } else { | ||
| ipv6 = ipPart; | ||
| } |
| // Windows guest that has not obtained a DHCP lease yet and self-assigned an APIPA address | ||
| private static String VIRSH_DOMIF_OUTPUT_WINDOWS_APIPA = " Name MAC address Protocol Address\n" + // | ||
| "-------------------------------------------------------------------------------\n" + // | ||
| " Ethernet 02:01:00:d0:00:87 ipv6 fe80::df84:2984:e396:8ac3%6/64\n" + // | ||
| " - - ipv4 169.254.149.120/16\n" + // | ||
| " Loopback Pseudo-Interface 1 ipv6 ::1/128\n" + // | ||
| " - - ipv4 127.0.0.1/8\n"; | ||
|
|
||
| // Same Windows guest once the DHCP lease has been obtained | ||
| private static String VIRSH_DOMIF_OUTPUT_WINDOWS_DHCP = " Name MAC address Protocol Address\n" + // | ||
| "-------------------------------------------------------------------------------\n" + // | ||
| " Ethernet 02:01:00:d0:00:87 ipv6 fd00:ac19:0:1910:0:d3fc:4177:2c32/128\n" + // | ||
| " - - ipv6 fe80::df84:2984:e396:8ac3%6/64\n" + // | ||
| " - - ipv4 172.25.16.236/22\n" + // | ||
| " - - ipv4 169.254.149.120/16\n" + // | ||
| " Loopback Pseudo-Interface 1 ipv6 ::1/128\n" + // | ||
| " - - ipv4 127.0.0.1/8\n"; |
| // a link-local (APIPA) address recorded before the guest obtained its DHCP lease is not a valid instance IP, | ||
| // clear it so it is no longer exposed and the NIC is retried as one without an IP | ||
| if (NetUtils.isLinkLocalIp4(nic.getIPv4Address())) { | ||
| logger.debug("Clearing link-local IP {} recorded for NIC {}", nic.getIPv4Address(), nic); | ||
| nic.setIPv4Address(null); | ||
| _nicDao.update(nic.getId(), nic); | ||
| } |
|
@blueorangutan package |
|
@nvazquez a [SL] Jenkins job has been kicked to build packages. It will be bundled with KVM, XenServer and VMware SystemVM templates. I'll keep you posted as I make progress. |
|
Packaging result [SF]: ✔️ el8 ✔️ el9 ✔️ el10 ✔️ debian ✔️ suse15. SL-JID 19542 |
|
@blueorangutan test |
|
@nvazquez a [SL] Trillian-Jenkins test job (ol8 mgmt + kvm-ol8) has been kicked to run smoke tests |
|
[SF] Trillian test result (tid-17132)
|
The KVM agent parsed the IPv6 address from 'virsh domifaddr --source agent' but discarded it, so nics.ip6_address was never set for external-DHCP/L2 networks. - Return the IPv6 address in a new GetVmIpAddressAnswer (IPv4 stays in details for compatibility). - Report the first global IPv6 address, falling back to the first link-local one (zone suffix removed) when there is no global address. - Treat the retrieval as successful when the guest has an IPv4 address or a global IPv6 address, so IPv6-only guests are supported. A link-local IPv6 address alone does not count as success. - Store the IPv6 address in nics.ip6_address on the management server. - Add unit tests for the IPv4/IPv6 combinations.
|
@blueorangutan package |
|
@weizhouapache a [SL] Jenkins job has been kicked to build packages. It will be bundled with KVM, XenServer and VMware SystemVM templates. I'll keep you posted as I make progress. |
|
Packaging result [SF]: ✔️ el8 ✔️ el9 ✔️ el10 ✔️ debian ✔️ suse15. SL-JID 19568 |


Description
This PR an issue observed on L2 Networks with external DHCP server:
On an L2 guest network with an external DHCP server, CloudStack learns a Windows VM's IP address as the self-assigned (APIPA / link-local) address
169.254.149.120. It recorded that as the NIC's IP and never refreshed it. More than 30 minutes later,listVirtualMachinesstill reports169.254.149.120, while the guest really has172.25.16.236(DHCP). The QEMU guest agent reports172.25.16.236, and SSH on172.25.16.236:22is reachable.Types of changes
Feature/Enhancement Scale or Bug Severity
Feature/Enhancement Scale
Bug Severity
Screenshots (if appropriate):
How Has This Been Tested?
How did you try to break this feature and the system with this change?