Add cloud-init example for guest DNS resolver configuration

[ndecandia]

What this PR does / why we need it:

This PR improves the DNS records documentation by adding a practical cloud-init example for configuring the guest DNS resolver.

The current documentation explains the requirement for options ndots:2 or higher when resolving short names such as myvmi.mysubdomain, but it does not provide an example on how to configure the guest operating system.

The added example demonstrates how to configure DNS settings using cloud-init in a persistent and systemd-resolved friendly way.

Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):

Fixes #

Special notes for your reviewer:

This is a documentation-only improvement.

Checklist

• Design: not required
• PR: The PR description is expressive enough and will help future contributors
• Code: not applicable
• Refactor: not applicable
• Upgrade: not applicable
• Testing: not applicable
• Documentation: user-guide update included
• Community: not required

Release note:

NONE

[kubevirt-bot]

Hi @ndecandia. Thanks for your PR.

I'm waiting for a kubevirt member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work.

Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[jean-edouard]

/approve

[kubevirt-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: jean-edouard

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• docs/network/OWNERS [jean-edouard]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[EdDev]

Thanks for adding this example to our docs.

[EdDev]

Thanks for adding this example.

A few suggestions:

1. Use networkData for the portable case

The DNS server and search domain configuration can be achieved more portably via networkData (cloud-init's native network config), without assuming systemd-resolved is present or requiring a runcmd service restart. Cloud-init network config (v2) is the canonical mechanism for this and works across distros:

- cloudInitNoCloud:
    userData: |
      #cloud-config
    networkData: |
      version: 2
      ethernets:
        eth0:
          dhcp4: true
          nameservers:
            addresses: [<cluster-dns-service-ip>]
            search:
              - default.svc.cluster.local
              - svc.cluster.local
              - cluster.local
  name: cloudinitdisk

2. The ndots gap remains unaddressed

The note immediately above the example specifically calls out ndots:2 as the requirement for short-name resolution, but the example does not set it. Note that systemd-resolved does not honor the ndots option — that lives in /etc/resolv.conf. The networkData approach also cannot set ndots, since cloud-init network config v1/v2 has no field for resolver options. If ndots:2 needs to be configured, a userData write_files entry targeting /etc/resolv.conf is required, but this is problematic as well. The example should either address this or clarify that search domains alone are sufficient in most cases.

3. Not in sync with the existing VMI manifest

The document already defines a complete VMI manifest with a cloudinitdisk volume at the top. The new example introduces a floating cloudInitNoCloud snippet that a reader cannot easily relate back to that manifest — it is unclear whether it is a replacement for the existing volume entry or an addition. The example should either show the full VMI manifest with the change applied, or explicitly state that it replaces the cloudinitdisk volume defined earlier.

4. Distro assumption

If the userData / systemd-resolved approach is kept, it should note that this is specific to distributions using systemd-resolved and will not work on RHEL-based systems using NetworkManager, or images using plain /etc/resolv.conf.