This message was deleted.
# harvester
a
This message was deleted.
a
I thought VM hostnames were automatically set to the VM name in harvester without needing explicit configuration in cloud config?
(at least, it works for me when using an opensuse leap 15.5 minimal VM image)
a
I'm using an elemental image (Micro 5.5 based) and hopefully this would be the behaviour but instead it always defaults to the hostname "rancher-xxx" unless I specify it in cloud config
a
that's interesting ... and annoying šŸ˜•
I wonder what the difference is? (I mean, I assume there must be some piece of magic that's in the leap 15.5 image, that's not in the micro image...)
a
I’ve asked in #C028DVCAYLD, perhaps someone will know something.
šŸ‘ 1
b
I think you can set it with DHCP as well?
You'd need to specify MAC in the cloud config, but that might not be feasible.
a
SLE Micro 5.x doesn't include cloud-init (SLE Micro 6 does, at least in the qcow images), which I assume explains why it doesn't automatically pick up the VM hostname, whereas leap does (the leap and regular SLE 15 qcow images include cloud-init).
What I don't understand is -- given the micro 5.x image doesn't (or shouldn't) have cloud-init -- why setting the hostname in the cloud config works for you!
Possibly it's picked up by Ignition or Combustion, which are initialization tools included in SLE Micro?
m
So, just to clarify the context for all, the cloud-init config snippet is something that is introduced by Elemental and applies to SLE Micro installations performed via Elemental only.
@acoustic-country-10006, you may keep the hostname already applied on the booted VM before the registration (be it transient or statically assigned) using the Elemental HW Label:
Copy code
"${System Data/Runtime/Hostname}"
(see https://deploy-preview-349--elemental-docs-staging.netlify.app/hostname#keep-the-hostname-assigned-from-dhcp)
otherwise, if you can get harvester data from SMBIOS (try dmidecode on a VM there) you can use that data to feed the machineName
a
Hey, thanks Francesco - I'm able to keep the transient host name just fine, it's more setting what the transient host name is so I don't get the default rancher-1234...
I'd rather not go down the DHCP route since that's more config elsewhere, hence trying to get the name from Harvester so it's nice and self contained and saves me some steps
I had wondered if Harvester puts anything in the SMBIOS, that would be handy. I'll take a look, thanks
m
Yep, probably checking SMBIOS is the best bet šŸ¤”
a
I'd like to understand the mechanism by which other OSes get the name from Harvester, perhaps this is what they do
m
Good point, I don't know this ^^ (anyone from Harvester team?) but for sure, this is really a good thing to improve. If there is another way to get that data from the booted host, we can extend the HW Labels in Elemental, so that data from Harvester can be filled in the Elemental MachineRegistration (for the hostname or even labels to apply to the MachineInventories). It would be a nice improvement!
a
Exactly!
h
@acoustic-country-10006 do you use the
kvm
flavor of the Micro-Elemental images ? Only this has
qemu-guest-agent
installed which might be needed to transfer the hostname from Harvester šŸ¤”
a
I’m using my own derivative but this includes the guest agent, which seems to be working correctly since I can see info being pulled from the VM into the bits of the Harvester GUI that require it
Copy code
elemental-1:~ # dmidecode
# dmidecode 3.4
Getting SMBIOS data from sysfs.
SMBIOS 2.8 present.
10 structures occupying 403 bytes.
Table at 0x7F908000.

Handle 0x0100, DMI type 1, 27 bytes
System Information
        Manufacturer: KubeVirt
        Product Name: None
        Version: pc-q35-7.1
        Serial Number: Not Specified
        UUID: b146b974-251d-5687-989f-07725f25e035
        Wake-up Type: Power Switch
        SKU Number: Not Specified
        Family: KubeVirt

Handle 0x0300, DMI type 3, 22 bytes
Chassis Information
        Manufacturer: QEMU
        Type: Other
        Lock: Not Present
        Version: pc-q35-7.1
        Serial Number: Not Specified
        Asset Tag: Not Specified
        Boot-up State: Safe
        Power Supply State: Safe
        Thermal State: Safe
        Security Status: Unknown
        OEM Information: 0x00000000
        Height: Unspecified
        Number Of Power Cords: Unspecified
        Contained Elements: 0
        SKU Number: Not Specified

Handle 0x0400, DMI type 4, 42 bytes
Processor Information
        Socket Designation: CPU 0
        Type: Central Processor
        Family: Other
        Manufacturer: QEMU
        ID: C1 06 03 00 FF FB 8B 0F
        Version: pc-q35-7.1
        Voltage: Unknown
        External Clock: Unknown
        Max Speed: 2000 MHz
        Current Speed: 2000 MHz
        Status: Populated, Enabled
        Upgrade: Other
        L1 Cache Handle: Not Provided
        L2 Cache Handle: Not Provided
        L3 Cache Handle: Not Provided
        Serial Number: Not Specified
        Asset Tag: Not Specified
        Part Number: Not Specified
        Core Count: 2
        Core Enabled: 2
        Thread Count: 1
        Characteristics: None

Handle 0x1000, DMI type 16, 23 bytes
Physical Memory Array
        Location: Other
        Use: System Memory
        Error Correction Type: Multi-bit ECC
        Maximum Capacity: 3996 MB
        Error Information Handle: Not Provided
        Number Of Devices: 1

Handle 0x1100, DMI type 17, 40 bytes
Memory Device
        Array Handle: 0x1000
        Error Information Handle: Not Provided
        Total Width: Unknown
        Data Width: Unknown
        Size: 3996 MB
        Form Factor: DIMM
        Set: None
        Locator: DIMM 0
        Bank Locator: Not Specified
        Type: RAM
        Type Detail: Other
        Speed: Unknown
        Manufacturer: QEMU
        Serial Number: Not Specified
        Asset Tag: Not Specified
        Part Number: Not Specified
        Rank: Unknown
        Configured Memory Speed: Unknown
        Minimum Voltage: Unknown
        Maximum Voltage: Unknown
        Configured Voltage: Unknown

Handle 0x1300, DMI type 19, 31 bytes
Memory Array Mapped Address
        Starting Address: 0x00000000000
        Ending Address: 0x0007FFFFFFF
        Range Size: 2 GB
        Physical Array Handle: 0x1000
        Partition Width: 1

Handle 0x1301, DMI type 19, 31 bytes
Memory Array Mapped Address
        Starting Address: 0x00100000000
        Ending Address: 0x00179BFFFFF
        Range Size: 1948 MB
        Physical Array Handle: 0x1000
        Partition Width: 1

Handle 0x2000, DMI type 32, 11 bytes
System Boot Information
        Status: No errors detected

Handle 0x0000, DMI type 0, 26 bytes
BIOS Information
        Vendor: EFI Development Kit II / OVMF
        Version: 0.0.0
        Release Date: 02/06/2015
        Address: 0xE8000
        Runtime Size: 96 kB
        ROM Size: 64 kB
        Characteristics:
                BIOS characteristics not supported
                Targeted content distribution is supported
                UEFI is supported
                System is a virtual machine
        BIOS Revision: 0.0

Handle 0xFEFF, DMI type 127, 4 bytes
End Of Table
Here’s the output of dmidecode on one of my VMs. The machine name in Harvester is elemental-1 and in this case I’ve set the hostname through cloud-config. There doesn’t seem to be anything in here that looks like the Harvester machine name
I’m thinking I’ll have a look at the KubeVirt docs and also the output of dmidecode on a VM where the OS does automatically inherit the Harvester VM name as it’s hostname, iirc Leap or Ubuntu both do this
From the KubeVirt docs it seems all you should need to do is set spec.hostname, which Harvester seems to be doing correctly. Here’s the VirtualMachine YAML Harvester generated for my VM as an example:
Copy code
apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  annotations:
    ...
  labels:
    harvesterhci.io/creator: harvester
    harvesterhci.io/os: SLEs
  managedFields:
    ...
  name: elemental-1
  namespace: default
  resourceVersion: '5618605'
  uid: bfca8492-6ddb-4fd3-bd65-93594ae06baa
spec:
  runStrategy: RerunOnFailure
  template:
    metadata:
      annotations:
        harvesterhci.io/sshNames: '["default/robert-claphamroad-rwbl-online"]'
      creationTimestamp: null
      labels:
        harvesterhci.io/vmName: elemental-1
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
              - matchExpressions:
                  - key: network.harvesterhci.io/mgmt
                    operator: In
                    values:
                      - 'true'
      architecture: amd64
      domain:
        cpu:
          cores: 2
          sockets: 1
          threads: 1
        devices:
          disks:
            ...
          tpm: {}
        features:
          acpi:
            enabled: true
        firmware:
          bootloader:
            efi:
              secureBoot: false
        machine:
          type: q35
        memory:
          guest: 3996Mi
        resources:
          limits:
            cpu: '2'
            memory: 4Gi
          requests:
            cpu: 125m
            memory: 2730Mi
      evictionStrategy: LiveMigrateIfPossible
      hostname: elemental-1
      networks:
        - multus:
            networkName: default/virtual
          name: default
      terminationGracePeriodSeconds: 120
      volumes:
        ...
status:
  ...
I suspect it’s more to do with how the guest OS consumes this šŸ¤” . If the Elemental generated images have some logic in the boot stages that generate the unique rancher-xxx hostname unless one’s specified via DHCP or cloud init, perhaps this may just be circumventing whatever is provided by kubevirt
Looking at https://github.com/rancher/elemental/blob/main/framework/files/system/oem/03_hostname.yaml where I think this happens… I guess my hostname hasn’t made it to
/etc/hostname
by this point, I’m not sure why though!
h
As you're building your own image, you could inject your own
03_hostname.yaml
šŸ˜‰
a
you read my mind šŸ˜‰
šŸ˜† 1
just waiting for my new image to push, I’d like to see the state of
etc/hostname
, I’m wondering if what kubevirt provides will only set the transient hostname and that doesn’t make it into here or something
only guesses at this point though, I didn’t even know the difference between transient/static till last week šŸ˜‚
m
šŸ˜† So, thanks for the useful sharing here Robert. So, guess you are going to try to drop 03_hostname.yaml... let us know if that helps. One thing to keep in mind is that the final hostname will be set on the machines when they become part of a cluster: in particular, the hostname that will be set (this time statically) is the name of the corresponding MachineInventory resource. The corresponding MachineInventory resource is created at registration time, i.e., the first time the machine boots and contacts the Elemental Operator endpoint (at the Rancher url). You need:
Copy code
machineName: "${System Data/Runtime/Hostname}"
in the MachineRegistration, otherwise a random
m-$UUID
will be generated and used as the name of the tracking MachineInventory, and that same name will be applied as a static hostname on the machine when provisioning RKE2 or K3s, replacing whatever hostname the machine may have.
a
correct, I’m not putting this test machine into a cluster so I don’t need to worry about hostname modifications further along the process for this test. I’ve already got the machineName part in my registration endpoint which works nicely for that step
So, my test machine is just defaulting to the hostname ā€œlocalhostā€, and
/etc/hostname
doesn’t exist.
I guess I need to find out more about how a more standard OS typically gets it’s hostname from whatever KubeVirt supplies
I’m not sure if this mechanism is particularly different for KubeVirt compared to regular libvirt/kvm, perhaps I’ll find something handy in that world
If anyone’s curious, based on this spec it doesn’t look like hostname should ever appear in DMI/SMBIOS https://www.dmtf.org/sites/default/files/standards/documents/DSP0134_3.2.0.pdf
@ambitious-daybreak-95996 were you using an ISO or a qcow2 disk for your leap VM? In my testing when I use an ISO and do an install it doesn’t pick up the Harvester VM name, but when I use the cloud image, this gets set as the hostname just fine. (Note I’m actually using tumbleweed as I had images handy)
I think there’s something here šŸ¤”
It looks like the OpenStack cloud images that successfully get their hostname from the Harvester VM name are using the
set_hostname
cloud-init
module https://cloudinit.readthedocs.io/en/latest/reference/modules.html#set-hostname to do this
what I haven’t worked out yet is how that cloud-init module is actually getting the hostname from Harvester/kubeVirt since I didn’t specify it in my cloud-config
Got it!!! As well as the user-data cloud-config we provide through Harvester, cloud-init also supports a _metadata_ datasource, this typically contains instance information and can be provided by a cloud service such as OpenStack or Harvester through various means. I remembered from poking around VM yaml that Harvester creates a small disk for cloud-init data, and sure enough if I mount this I can see the meta-data which includes the Harvester VM name:
šŸ™Œ 2
Given that elemental already uses cloud-init, I’m hoping I can just point it at this extra config and it will ā€œjust workā€ ā„¢ļø
Unfortunately I can’t seem to easily point it at this, the reason being that the cd-rom datasource provider that’s baked into derivatives built using the elemental-toolkit only looks for files with the names
user-data
&
config
. So I can point it at the cloud-init drive (this actually happens automatically), but not the correct file within that drive. I think at this point I’ll continue this thread in #C028DVCAYLD since this definitely isn’t a Harvester issue. Many thanks for all your help.
a
@acoustic-country-10006 I used the qcow image for my leap VM
a
Thanks, that lines up with my findings
šŸ‘ 1