Problem establishing SSH connection with Fedora 21 and Parallels

[ncdc]

Fedora 21 made a change (https://bugzilla.redhat.com/show_bug.cgi?id=560361#c40) where its DHCP client sends a DUID as the client identifier, instead of the MAC address of the NIC. If no DUID exists, it will generate one and save it for future use. During the installation of Fedora 21, the installer system generates a DUID for itself. This DUID is not copied from the installer system to the target system being installed. When the installation is finished and the VM reboots, now the target system is running and it doesn't have a DUID, so it generates its own.

This would be fine except that the DHCP server in Parallels apparently assigns DHCP addresses based on the DUID. During installation, the DHCP server assigns an IP address based on the installer's DUID. When the target system boots, the DHCP server generates a different IP address based on the target system's DUID.

The Parallels driver code looks for the first entry in the Parallels DHCP leases file matching the VM's NIC's MAC address. The problem is that in this particular situation, there are multiple entries for the same MAC, because it's been assigned multiple IP addresses - 1 for each DUID. And the Parallels driver, at least in my testing, always picks the wrong lease, so it's never able to SSH to the VM.

Here's an entry from /Library/Preferences/Parallels/parallels_dhcp_leases where the DUID has just the MAC address:

10.211.55.54="1416593294,1800,001c42729b34,01001c42729b34"

And here are multiple entries for the same MAC address where the DUID changed (during installation, after installation):

10.211.55.73="1418242801,1800,001c42059da8,ff42059da8000100011c1b6055001c42059da8"
10.211.55.74="1418242797,1800,001c42059da8,ff42059da8000100011c1b6065001c42059da8"

I've considered modifying the Parallels driver to detect when the installation is finished and generate a new MAC address for the NIC prior to running common.StepConnectSSH, but I'm not sure if there's a better way. Or if this is really either Fedora's or Parallel's problem. What do you think?

[ncdc]

I've modified my copy of packer locally so that it waits for the kickstart installation to finish (meaning the kickstart must have shutdown specified and not reboot), regenerate the MAC address, and then do the SSH connection. It works, but feels really hackish.

[rickard-von-essen]

Interesting, I was just downloading Fedora 21 to give it a try. Good report, I'll look into it tomorrow.

@legal90 what is your opinion on this?

[ncdc]

@rickard-von-essen @legal90 if you want to see my hacky edits, let me know.

[ncdc]

@rickard-von-essen oh, and Parallels Tools won't compile correctly for kernels 3.17.2 and newer. I have a patch to work around it, and I've filed a report with customer support. And there's http://forum.parallels.com/threads/parallels-tools-breaks-in-fedora-20-kernel-3-17-2.327166/ as well.

[legal90]

@rickard-von-essen I can see the following solutions here: 1) Add selection logic to the IpAddress func. We should get the latest lease (by timestamp) for the specified MAC address. 2) Either we can regenerate the MAC address, as @ncdc have suggested above.

I think that the first one is better.

[ncdc]

+1 to the timestamp approach. I have seen some interesting behavior where the lease expirations are out of order for what I would expect, although I don't think it should affect this approach. For example:

10.211.55.63="1418232059,1800,001c42ba882a,ff42ba882a000100011c1b365f001c42ba882a"
10.211.55.64="1418232055,1800,001c42ba882a,ff42ba882a000100011c1b366f001c42ba882a"
10.211.55.65="1418235578,1800,001c42ba882a,ff42ba882a000100011c1b3716001c42ba882a"

These 3 IPs were all assigned to the same MAC. The 3rd, .65, was the IP that the VM received after the installation had finished and it rebooted, i.e. this is the SSH IP. For some reason .64's expiration is before .63's, which isn't what I'd expect. Here's the relevant output from parallels.log:

12-10 11:50:40.109 I /prl_naptd:74809:507/ dhcp_discover: lease allocated, dst_hw = 03:00:41:10:a2:7f, ip_offer = 10.211.55.63
12-10 11:50:40.109 I /prl_naptd:74809:507/ dhcp_req: hw = 00:1c:42:ba:88:2a, ip_requested: 10.211.55.63, saved_lease: 10.211.55.63
12-10 11:50:55.835 I /prl_naptd:74809:507/ dhcp_discover: lease allocated, dst_hw = 02:00:00:00:00:00, ip_offer = 10.211.55.64
12-10 11:50:55.836 I /prl_naptd:74809:507/ dhcp_req: hw = 00:1c:42:ba:88:2a, ip_requested: 10.211.55.64, saved_lease: 10.211.55.64
12-10 11:50:59.171 I /prl_naptd:74809:507/ dhcp_req: hw = 00:1c:42:ba:88:2a, ip_requested: 10.211.55.63, saved_lease: 10.211.55.63
12-10 11:53:42.200 I /prl_naptd:74809:507/ dhcp_discover: lease allocated, dst_hw = 02:00:00:00:00:00, ip_offer = 10.211.55.65
12-10 11:53:42.200 I /prl_naptd:74809:507/ dhcp_req: hw = 00:1c:42:ba:88:2a, ip_requested: 10.211.55.65, saved_lease: 10.211.55.65

I would say given that there will likely be a few minutes in between when IP addresses are assigned during the installation process (.63 and .64 above) and when the VM has rebooted and is ready to be provisioned by Packer (.65 above), it's probably ok just to go with latest expiration timestamp.

[rickard-von-essen]

I think the correct way is to pick the last line which matches. I expect that it is the last (most recent) lease and should be the correct (if any). I'll try to do a patch tonight.

@legal90 can you confirm that leases are added in most recent in the end of the file? (per NIC)

[rickard-von-essen]

Created a small patch that always takes the last matching line in the lease file. Please review and verify.

[ncdc]

@rickard-von-essen the patch looks good