Description of problem: Can't launch volume as instance on RHOSP16.1 if instance name ends with a number Version-Release number of selected component (if applicable): id: RHOS-16.1-RHEL-8-20200723.n.0 Package version of compute node of RHOSP16.1 libvirt-client-6.0.0-17.2.module+el8.2.0+6629+3fc0f2c2.x86_64 qemu-kvm-4.2.0-19.module+el8.2.0+6296+6b821950.x86_64 overcloud-novacompute-0 4.18.0-193.13.2.el8_2.x86_64 How reproducible: 100% Steps to Reproduce: 1. Convert a guest from VMware to openstack by v2v # virt-v2v -ic vpx://root.73.141/data/10.73.75.219/?no_verify=1 -it vddk -io vddk-libdir=/home/vmware-vix-disklib-distrib -io vddk-thumbprint=1F:97:34:5F:B6:C2:BA:66:46:CB:1A:71:76:7D:6B:50:1E:03:00:EA esx6.7-ubuntu18.04-x86_64 -o openstack -oo server-id=rhel8.3-v2v-osp16-server -oo server-id=rhel8.3-v2v-osp16-server -oo os-username=admin -oo os-auth-url=http://192.168.24.16:5000 -oo os-password=redhat -oo os-project-name=admin -oo os-user-domain-name=default -oo os-project-domain-name=default -oo os-identity-api-version=3 -ip /home/passwd [ 1.6] Opening the source -i libvirt -ic vpx://root.73.141/data/10.73.75.219/?no_verify=1 esx6.7-ubuntu18.04-x86_64 -it vddk -io vddk-libdir=/home/vmware-vix-disklib-distrib -io vddk-thumbprint=1F:97:34:5F:B6:C2:BA:66:46:CB:1A:71:76:7D:6B:50:1E:03:00:EA [ 3.3] Creating an overlay to protect the source from being modified [ 4.2] Opening the overlay [ 13.6] Inspecting the overlay [ 21.9] Checking for sufficient free disk space in the guest [ 21.9] Estimating space required on target for each disk [ 21.9] Converting Ubuntu 18.04.3 LTS to run on KVM virt-v2v: warning: could not determine a way to update the configuration of Grub2 virt-v2v: This guest has virtio drivers installed. [ 97.2] Mapping filesystem data to avoid copying unused and blank areas [ 101.8] Closing the overlay [ 102.1] Assigning disks to buses [ 102.1] Checking if the guest needs BIOS or UEFI to boot [ 102.1] Initializing the target -o openstack Failed to set volume read-only access mode flag: Invalid volume: Volume 877aca84-9fc4-41c3-9bad-ccd579f7f096 status must be available to update readonly flag, but current status is: creating. (HTTP 400) (Request-ID: req-691b758b-b495-4d80-8dcd-0f60563b59e2) [ 122.2] Copying disk 1/1 to /dev/disk/by-id/virtio-877aca84-9fc4-41c3-9 (raw) (100.00/100%) [ 614.4] Creating output metadata [ 621.4] Finishing off 2.Try to launch the volume as instance on OSP16 dashboard, but find failed to launch volume as instance if instance name ends with a number, pls refer to screenshot "instance-name-end-with-number.png" 3.Check nova-compute log in compute node, found below error: 2020-08-25 13:21:03.737 7 ERROR nova.compute.manager [req-dd27a4f5-432f-4656-bd58-3722531493dc 9c197202fce24d9f8dcc95c23d4af583 3ccefcef669147dcbd6139347a5da986 - default default] [instance: 37ea6a40-e236-4b12-9845-988215ec1d10] Failed to build and run instance: neutronclient.common.exceptions.BadRequest: Invalid input for dns_name. Reason: 'ubuntu18.04' not a valid PQDN or FQDN. Reason: TLD '04' must not be all numeric. Actual results: As above description Expected results: Can launch volume as instance on RHOSP16.1 if instance name ends with a number Additional info： Can launch volume as instance on RHOSP14 if instance name ends with a number
Created attachment 1712539 [details] instance-name-end-with-number.png
Created attachment 1712540 [details] nova-compute.log
I've updated the title as this isn't related to the instance being spawned from a virt-v2v based volume, only that the name ends with a digits and this breaks one of our requests to neutron.
The problem is that Nova passes the VM name to Neutron's dns_name port field, and if the VM name contains a period, Neutron will think everything after the period is a TLD code. In this case, it thinks 'ubuntu18.04' is a FQDN equivalent to redhat.com, with 'ubuntu18' playing the part of 'redhat', and '04' playing the part of 'com'. However, all-numeric TLD codes aren't allowed, so Neutron refuses. We can't just add this validation to Nova, because for instances without ports, or any other use case where the port's dns_name is not set to the VM's name, it's perfectly valid to have a VM called 'ubuntu18.04'. Because this is an edge case, and the impact is fairly minor, and there's no customer case, and of the limited capacity of the Compute DFG (us!), I want to be brutally honest and close this as WONTFIX. I agree it's not great UX, but we have to pick our battles, and we have others that have much greater impact. Cheers!
Just got a customer request for this bug fix, see attached case. Customer said - Can we please get this escalated and placed onto priolist?
sent email to rhosp-prio list following process. Also just reproduced on 16.1.2 lab env to confirm this fails for any attempt to create a VM name ending in .# $ openstack server create --image $image --nic net-id=$privnet --flavor $flavor --key-name $keypair --security-group $secgroup allang-vm.1 (overcloud) [stack@undercloud-0 ~]$ openstack server list +--------------------------------------+-------------+--------+-----------------------------------------+--------+--------+ | ID | Name | Status | Networks | Image | Flavor | +--------------------------------------+-------------+--------+-----------------------------------------+--------+--------+ | 81cc0485-6e21-4ca1-aab4-bb560b1806e8 | allang-vm.1 | ERROR | | cirros | |
FYI, just confirmed it did used to work in RHOSP 13, test in lab running 13.0.12: $ openstack server create --image $image --nic net-id=$privnet --flavor $flavor --key-name $keypair --security-group $secgroup allang-vm.1 (overcloud) [stack@undercloud-0 ~]$ openstack server list +--------------------------------------+-------------+--------+-----------------------------------------+--------+-------------+ | ID | Name | Status | Networks | Image | Flavor | +--------------------------------------+-------------+--------+-----------------------------------------+--------+-------------+ | 1e5a574f-7566-4274-a057-68151b9b4c74 | allang-vm.1 | ACTIVE | allang-privnet=172.16.1.152 | cirros | allang-tiny |
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 (Red Hat OpenStack Platform 16.1.6 bug fix and enhancement 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/RHBA-2021:2097