Bug 1693532
| Summary: | Both the source pod and target pod network IP is Unreachable after migration succeeded | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Container Native Virtualization (CNV) | Reporter: | Yan Du <yadu> | ||||
| Component: | Virtualization | Assignee: | Vladik Romanovsky <vromanso> | ||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Denys Shchedrivyi <dshchedr> | ||||
| Severity: | high | Docs Contact: | |||||
| Priority: | high | ||||||
| Version: | 2.0 | CC: | cnv-qe-bugs, danken, fdeutsch, ipinto, ncredi, sgordon, sgott, vromanso | ||||
| Target Milestone: | --- | ||||||
| Target Release: | 2.1.0 | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | hco-bundle-registry-container-v2.1.0-47 | Doc Type: | Known Issue | ||||
| Doc Text: |
Cause: Performing a VM live migration with a pod network backed vNIC
Consequence: The VM is not reachable through that vNIC anymore after the live migration
Workaround (if any): Use an additional multus backed network to keep it reachable after migration
Result:
|
Story Points: | --- | ||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2019-11-04 15:08:55 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
Yan Du
2019-03-28 06:22:35 UTC
Yan, please include in such cases the spec of the vmi. Did you define a VM with the pod network attached to it? Created attachment 1550150 [details]
vm spec
(In reply to Dan Kenigsberg from comment #1) > Did you define a VM with the pod network attached to it? For this bug, I only defined the default network interface in the vm. Please refer to the yaml file I attached in the bug. For L2 network, I have added a comment in JIRA card, please kindly note. Thanks The spec you've attached does not mention any network/interface. Migration cannot really work if you pass the default network to the VM. Please modify this bug to ask the virt team to block migration in this case. If I understand correctly, I think when we start the vm, the vmi will use a default network and interface in VMI as below. (The VM spec is from https://github.com/kubevirt/kubevirt/blob/master/cluster/examples/vm-cirros.yaml) And it should be a correct vm spec since I did the migration according virt-team's suggestion. interfaces: - bridge: {} name: default features: acpi: enabled: true firmware: uuid: 0d2a2043-41c0-59c3-9b17-025022203668 machine: type: q35 resources: requests: memory: 128M networks: - name: default pod: {} If I misunderstand, please feel free to comment which kind of the network/interface do you want me to provide. Thanks, Yan. You have now specified the network and interface, which I had requested back in comment 1. interfaces: - bridge: {} name: default should not be used in conjunction with migration. It cannot really work, since for most CNIs, the IP on the destination Pod is going to change and surprise the guest. imho migration should be blocked if default+bridge exist in the VMI. Test on latest CNV 2.1, VM migration with pod network is denied. VM migration with multus network works well. $ oc create -f mig_job.yaml Error from server: error when creating "job": admission webhook "migration-create-validator.kubevirt.io" denied the request: Cannot migrate VMI, Reason: InterfaceNotLiveMigratable, Message: cannot migrate VMI with a bridge interface connected to a pod network |