Bug 2166510 - Headless service functionality loss for OCP-V VMs on live migration
Summary: Headless service functionality loss for OCP-V VMs on live migration
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Container Native Virtualization (CNV)
Classification: Red Hat
Component: Virtualization
Version: 4.11.2
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ---
: 4.13.1
Assignee: lpivarc
QA Contact: zhe peng
URL:
Whiteboard:
Depends On:
Blocks: 2176785 2176787
TreeView+ depends on / blocked
 
Reported: 2023-02-02 04:10 UTC by Pawan kumar Vilayatkar
Modified: 2025-02-19 09:25 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 2176785 2176787 (view as bug list)
Environment:
Last Closed: 2023-06-20 13:41:05 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github kubevirt kubevirt pull 9189 0 None Merged Remove hostname limitation for migrations 2023-04-13 13:33:54 UTC
Github kubevirt kubevirt pull 9380 0 None Merged [release-0.59] Remove hostname limitation for migrations 2023-04-13 13:33:51 UTC
Red Hat Issue Tracker CNV-24921 0 None None None 2023-02-02 04:13:20 UTC
Red Hat Product Errata RHEA-2023:3686 0 None None None 2023-06-20 13:41:26 UTC

Description Pawan kumar Vilayatkar 2023-02-02 04:10:35 UTC
Description of problem:
Created a headless service and populated to VMs so they could be able to resolve the A record in an FQDN manner of: <vmi.spec.hostname>.<vmi.spec.subdomain>.<vmi.metadata.namespace>.svc.cluster.local.

Creation of their VMs seems to work, underlying Pod has its subdomain and hostname fields populated and resolution for the FQDN is functional.

However, when a live migration is triggered and the target Pod is created, it's created with the subdomain field populated but without the hostname field.


Version-Release number of selected component (if applicable):
All versions


How reproducible:
Always


Steps to Reproduce:

- Created a headless service. My env headless service "subdomain"
- Populated the VM yaml with subdomain and hostname :
~~
hostname: hostname
      networks:
      - name: nic
        pod: {}
      subdomain: mysubdomain <----- Headless service
~~

- Started VM and I can see the virt-launcher has a hostname and subdomain spec :

~~
# oc get pod virt-launcher -o yaml |egrep 'hostame|subdomain'
  hostname: hostname
  subdomain: mysubdomain
~
  

-- After live migration, the target virt-launcher pod is missing Hostname. The subdomain spec is still there.

~~
# oc get pod virt-launcher -o yaml |egrep 'hostame|subdomain'
 subdomain: mysubdomain
~~

Actual results:

The hostname spec is missing after VM live migration on virt-launcher pod.


Expected results:

The hostname spec should also be shown on the target virt-launcher pod after migration.

Comment 1 Dan Kenigsberg 2023-03-09 09:39:28 UTC
Customer requests backport to 4.11.z

Comment 4 zhe peng 2023-05-30 06:30:18 UTC
verify with build: CNV-v4.13.1.rhel9-40

step: 
1: Created a headless service. 
apiVersion: v1
kind: Service
metadata:
  name: subdomain
spec:
  clusterIP: None
  selector:
    app: test-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 3000 
2: create a vm with:
...
spec:
  hostname: "myvmi"
  subdomain: "mysubdomain"
  domain:
...
3: start vm and check virt-launcher
$ oc get pods virt-launcher-vm-fedora-zwsdf -o yaml | egrep 'hostname|subdomain'
  hostname: myvmi
  subdomain: mysubdomain

4: do livemigration
$ oc get pods
NAME                            READY   STATUS      RESTARTS   AGE
virt-launcher-vm-fedora-59htv   1/1     Running     0          20s
virt-launcher-vm-fedora-zwsdf   0/1     Completed   0          4m47s

after migration, check target virt-launcher
$ oc get pods virt-launcher-vm-fedora-59htv -o yaml | egrep 'hostname|subdomain'
        topologyKey: kubernetes.io/hostname
  hostname: myvmi
  subdomain: mysubdomain

move to verified.

Comment 10 errata-xmlrpc 2023-06-20 13:41:05 UTC
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 (OpenShift Virtualization 4.13.1 Images), 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-2023:3686

Comment 11 Dandre Crist 2025-02-19 09:25:53 UTC Comment hidden (spam)

Note You need to log in before you can comment on or make changes to this bug.