Kubevirt: failed to create virtual machine pod due to failed name validation

Created on 30 May 2018  路  11Comments  路  Source: kubevirt/kubevirt

Created a VM on OCP 3.10with the working-template from manageiq
I see the below message in the vm object status section

  status:
    conditions:
    - lastProbeTime: null
      lastTransitionTime: 2018-05-30T06:33:50Z
      message: 'failed to create virtual machine pod: Pod "virt-launcher-vparekh.test003-5cflf"
        is invalid: spec.hostname: Invalid value: "vparekh.test003": a DNS-1123 label
        must consist of lower case alphanumeric characters or ''-'', and must start
        and end with an alphanumeric character (e.g. ''my-name'',  or ''123-abc'',
        regex used for validation is ''[a-z0-9]([-a-z0-9]*[a-z0-9])?'')'
      reason: FailedCreate
      status: "False"
      type: Synchronized
    phase: Pending

Whole VM object

[root@cnv-executor-vparekhmiq-master1 ~]# oc get vms vparekh.test001 -o yaml 
apiVersion: kubevirt.io/v1alpha1
kind: VirtualMachine
metadata:
  annotations:
    presets.virtualmachines.kubevirt.io/presets-applied: kubevirt.io/v1alpha1
  clusterName: ""
  creationTimestamp: 2018-05-30T06:33:24Z
  finalizers:
  - foregroundDeleteVirtualMachine
  generateName: vparekh.test001
  generation: 1
  name: vparekh.test001
  namespace: default
  ownerReferences:
  - apiVersion: kubevirt.io/v1alpha1
    blockOwnerDeletion: true
    controller: true
    kind: OfflineVirtualMachine
    name: vparekh.test001
    uid: 4baad838-63d3-11e8-a395-fa163ebb795f
  resourceVersion: "160991"
  selfLink: /apis/kubevirt.io/v1alpha1/namespaces/default/virtualmachines/vparekh.test001
  uid: 5a8fa466-63d3-11e8-a395-fa163ebb795f
spec:
  domain:
    cpu:
      cores: 8
    devices:
      disks:
      - disk: {}
        name: registrydisk
        volumeName: registryvolume
      - disk: {}
        name: cloudinitdisk
        volumeName: cloudinitvolume
    firmware:
      uuid: bebee2cb-673e-516d-b253-9a6a0964b462
    machine:
      type: q35
    resources:
      requests:
        memory: 4Gi
  volumes:
  - name: registryvolume
    registryDisk:
      image: kubevirt/fedora-cloud-registry-disk-demo:latest
  - cloudInitNoCloud:
      userDataBase64: I2Nsb3VkLWNvbmZpZwpwYXNzd29yZDogYXRvbWljCnNzaF9wd2F1dGg6IFRydWUKY2hwYXNzd2Q6IHsgZXhwaXJlOiBGYWxzZSB9Cg==
    name: cloudinitvolume
status:
  conditions:
  - lastProbeTime: null
    lastTransitionTime: 2018-05-30T06:33:23Z
    message: 'failed to create virtual machine pod: Pod "virt-launcher-vparekh.test001-s4fnt"
      is invalid: spec.hostname: Invalid value: "vparekh.test001": a DNS-1123 label
      must consist of lower case alphanumeric characters or ''-'', and must start
      and end with an alphanumeric character (e.g. ''my-name'',  or ''123-abc'', regex
      used for validation is ''[a-z0-9]([-a-z0-9]*[a-z0-9])?'')'
    reason: FailedCreate
    status: "False"
    type: Synchronized
  phase: Pending

good-first-issue help wanted kinbug

All 11 comments

@rmohr @pkliczewski I think validation in manageiq was fine, not sure why this occurred

The name of the OVM / VM will be as used as hostname and for internal DNS by Kubernetes, and it must not contain a .. So you need to change the name of the OVM. Only lowercase alphanumeric characters and - are allowed, the latter not at first or last position.

@pkliczewski
this should to be added in manageiq validation as well

@vatsalparekh please create an issue in kubevirt provider to normalize the name and keep this one for kubevirt to refuse creating such ovm/vm.

should this have been catched by the crd validation @davidvossel ?

I was not aware of the . limitation (although it makes sense) for hostnames. We should adjust our validation or sanitize the vm name for dns.

should this have been catched by the crd validation @davidvossel ?

our validation webhook is limited to disks/volumes at the moment. We did this in order to get the general structure of the webhook merged without having to define every possible validation check immediately.

Now that the webhook is in, we need to begin expanding the validation to perform checks on additional fields as well.

IIUIC the proposed solution is to fix our validation to not permit dots (.)? @rmohr @davidvossel @slintes ?

Like Roman already wrote, there are 2 options:

a) validate and reject invalid names
b) sanitize the name (probably somewhere around the place where default values are set, because the validation webhook can not modify the VM)

Be aware that this is not only about ., the name field only allows lowercase alphanumeric characters and -, the latter not at first or last position.
From a k8s user's perspective I would be fine with validation and rejection, because we are used to this from Deployments/Pods. Not sure about the virtualization user's perspective :)

Okay, let's go with a) - align a to how k8s does it.

Okay, let's go with a) - align a to how k8s does it.

Names are already validated. Not allowing "." in the name was not my intention when we added hostname and subdomain. What k8s does, is sanitizing the pod name and use the sanitized form as the hostname of the pod. For instance

  • ngin.x is sanitized to ngin
  • my-super.hostname is sanitized to my-super

    • Finally I think that a maximum host name length also exists (not sure)

So it may make sense that we by default use this sanitized variation for the hostname field and cloud-init if no hostname was specified on the vm and we fall back to the vm name. In the case that the hostname field is directly set on the vm we should do the same validation like k8s does on the hostname field on the pod.

Was this page helpful?
0 / 5 - 0 ratings