Bug 1708680
| Summary: | Restart doesn't work(can't get ip) for rhel76 which has cloud-init config | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Container Native Virtualization (CNV) | Reporter: | zhe peng <zpeng> | ||||||||
| Component: | Virtualization | Assignee: | Vladik Romanovsky <vromanso> | ||||||||
| Status: | CLOSED ERRATA | QA Contact: | Denys Shchedrivyi <dshchedr> | ||||||||
| Severity: | medium | Docs Contact: | |||||||||
| Priority: | medium | ||||||||||
| Version: | 1.4.0-2 | CC: | cnv-qe-bugs, eterrell, fdeutsch, ipinto, knoel, ncredi, pousley, ribarry, sgordon, sgott, vromanso | ||||||||
| Target Milestone: | --- | ||||||||||
| Target Release: | 2.1.0 | ||||||||||
| Hardware: | All | ||||||||||
| OS: | Unspecified | ||||||||||
| Whiteboard: | |||||||||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |||||||||
| Doc Text: | Story Points: | --- | |||||||||
| Clone Of: | Environment: | ||||||||||
| Last Closed: | 2019-10-31 14:08:47 UTC | Type: | Bug | ||||||||
| Regression: | --- | Mount Type: | --- | ||||||||
| Documentation: | --- | CRM: | |||||||||
| Verified Versions: | Category: | --- | |||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||
| Embargoed: | |||||||||||
| Attachments: |
|
||||||||||
|
Description
zhe peng
2019-05-10 14:46:16 UTC
Created attachment 1566707 [details]
vm definition file
Sorry for save a blank description, post here: Description of problem: create a rhel vm with cloud-config, after restart, vm can't get IP address. Version-Release number of selected component (if applicable): CNV 1.4 async How reproducible: always Steps to Reproduce: 1.create a vm 2.start vm #virtctl start vm #oc get vmi test-vm 2m Running 10.129.0.21 cnv-executor-zpeng-node1.example.com vm can get ip, then restart vm #virtctl restart test-vm after a while, check vm #oc get vmi test-vm 8m Running cnv-executor-zpeng-node2.example.com login to the vm, the interface didn't start Actual results: vm can't get ip Expected results: vm have ip address Additional info: Talk with Marcin, he suggest to file one bug and discuss if this is a real bug Zhe, please provide `oc get -o yaml $VMNAME` (replace $VMNAME) for the VM as well. So far my assumption is that the VM uses a bridge/masquerade binding with the pod network, and after start, the VM is getting a new mac address from the network, which will break networking isde the VM, as inside the VM the ifcfg* scripts were tied to the MAC used for the first boot. The resolution to this problem is: 1. for pod network have a stable address (requires https://jira.coreos.com/browse/CNV-1803) 2. For any additional network we depend on what the provide can provide We need to wait for oc get poutput to udnerstand what the situation with this vm is (1 or 2) Created attachment 1567816 [details]
vm yaml output
Thanks, I missed to say: oc get vmi $VMNAME - please this as well Created attachment 1567823 [details]
vmi yaml output
Zhe, does it also happen if you create (and start and stop and start) a VM from the UI? Hi Fabian, yes, I create a VM from UI wizard and still have this issue, I link vm yaml later. ui vm yaml file link: http://pastebin.test.redhat.com/762358 Thanks. Can you please also try this flow with CNV 2.0? IIRC the default bdining mode was changed to masquerade in CNV 2.0 UI flows, which might avoid this issue. Zhe, the other question: As a workaround can you try to remove the HWADDR line from the ifcfg* file after the first boot? After this, on later boots, the VM should still get an IP. dev and qe agreed to move this to 2.1, as it only impacts pod network interfaces (nto additional networks). A known issue bug #1709850 was filed to mention it in the 2.0 docs. This will be fixed by https://jira.coreos.com/browse/CNV-1802 Verified on hco-bundle-registry:v2.1.0-62 Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2019:3282 |