Show IP address of the VM created using inspect json

[cmoulliard]

Proposition

It could be very hard for a user to figure out what the IP address of the VM created is when DHCP is used. This is why I would like to propose to use the inspect json response to show it like the hostname of VM

Now

❯ http :60195/vm/inspect
HTTP/1.1 200 OK
Content-Length: 1318
Content-Type: application/json; charset=utf-8
Date: Fri, 17 Jan 2025 10:38:43 GMT

{
    "bootloader": {
        "createVariableStore": true,
        "efiVariableStorePath": "/Users/cmoullia/code/_temp/vfkit/dev/efi-variable-store",
        "kind": "efiBootloader"
    },
    "devices": [
        {
            "devName": "virtio-blk",
            "imagePath": "/Users/cmoullia/code/_temp/vfkit/fedora/Fedora-Cloud-41.raw",
            "kind": "virtioblk"
        },
        {
            "devName": "virtio-blk",
            "imagePath": "/Users/cmoullia/code/_temp/vfkit/fedora/cloudinit.iso",
            "kind": "virtioblk"
        },
        {
            "inputType": "keyboard",
            "kind": "virtioinput"
        },
        {
            "inputType": "pointing",
            "kind": "virtioinput"
        },
        {
            "kind": "virtionet",
            "macAddress": "5a:94:ef:e4:0c:ee",
            "nat": true
        },
        {
            "ignoreIfMissing": false,
            "installRosetta": true,
            "kind": "rosetta",
            "mountTag": "rosetta"
        },
        {
            "kind": "virtiorng"
        },
        {
            "kind": "virtiosock",
            "listen": true,
            "port": 1025,
            "socketURL": "/Users/cmoullia/code/_temp/vfkit/dev/default.sock"
        },
        {
            "kind": "virtioserial",
            "logFile": "/Users/cmoullia/code/_temp/vfkit/dev/default.log"
        },
        {
            "height": 600,
            "kind": "virtiogpu",
            "usesGUI": true,
            "width": 800
        },
        {
            "kind": "virtiofs",
            "mountTag": "user1",
            "sharedDir": "/Users/cmoullia/code/"
        },
        {
            "kind": "virtiosock",
            "listen": true,
            "port": 1024,
            "socketURL": "/var/folders/28/g86pgjxj0wl1nkd_85c2krjw0000gn/T/ignition.sock"
        }
    ],
    "ignition": {
        "configPath": "/Users/cmoullia/code/_temp/vfkit/dev/my-cfg.ign",
        "kind": "ignition",
        "socketPath": "/var/folders/28/g86pgjxj0wl1nkd_85c2krjw0000gn/T/ignition.sock"
    },
    "memoryBytes": 4294967296,
    "vcpus": 2
}

After

{
...
    "memoryBytes": 4294967296,
    "vcpus": 2,
    "vm": {
        "name: "cloud-name",
        "ip": "192.168.64.4"
     }
}

[gbraad]

This is related to: #242. As vfkit does not directly interact with the guest OS, it does therefore need to do this from the host.

[evidolob]

We may re/use code from CRC https://github.com/crc-org/machine-driver-hyperkit/blob/master/pkg/hyperkit/network.go

[cfergeau]

https://github.com/crc-org/crc/blob/main/pkg/drivers/vfkit/network_darwin.go has some code parsing the leases file, some of it can probably reused.

EDIT:  posted at the same time as Yevhen's comment ^^

[gbraad]

The question I have is; is this really the responsibility of the hypervisor driver. As in this case it is infrastructure and networking. If I had not used DHCP, but bridged, this would not have worked. And I can also not rely on the guest OS, as that might be a different type of OS.

[cfergeau]

When we have the information, it's worthwhile to provide it instead of telling everyone to go parse a file by themselves in a non obvious location.
It's similar to what we do for timesync or ignition or #208
This can be done without vfkit involvement, but it is still closely tied with the hypervisor, so we add helpers to things easier.

[nirs]

I'm using cloud-init runcmd to report the vm ip address to the serial console. This is kind of poor's man guest agent :-)

How it works:

1. Renaming the network interface to make it easier to locate
   https://github.com/nirs/vmnet-helper/blob/f6bc5d2cb511dbb6e64f1461a12fd0f9f1557d21/example#L451
2. Installing jq top make ip query nicer and more robust
   https://github.com/nirs/vmnet-helper/blob/f6bc5d2cb511dbb6e64f1461a12fd0f9f1557d21/example#L422
3. Writing the network interface ip to serial console
   https://github.com/nirs/vmnet-helper/blob/f6bc5d2cb511dbb6e64f1461a12fd0f9f1557d21/example#L427
4. The ip address can be fetched from the serial.log
   https://github.com/nirs/vmnet-helper/blob/f6bc5d2cb511dbb6e64f1461a12fd0f9f1557d21/example#L324

This is hacky and fragile, but it works nicely for vment shared network (replacing lookup in /var/db/dhcpd_leases), vmnet bridged network (replacing insecure arp), and tested with both vfkit and qemu (need different devices for the serial console).

Maybe it can be integrated into cloud init and improved to be more robust.