Assigning fixed IP to generated VDI desktops

[Miloslav Hůla]

Dne 01.11.2016 v 11:47 Simon Hobson napsal(a):
> Miloslav Hůla <miloslav.hula at gmail.com> wrote:
>
>> The basic steps are following:
>>
>> 1) prepare a golden image (the source Windows machine)
>> 2) generate the pool of windows desktops based on the golden
>>
>> Let's say, we are creating a pool of 50 office desktops. We are telling to VMware: "Create office-01 to office-50 from golden". The process for every new station is:
>>
>> a) Take golden with known MAC1 and hostname 'golden'.
>> b) Clone golden. The result is a windows machine with new random MAC2, but hostname is still 'golden'.
>> c) Boot up new machine and run customization scripts. The result is the hostname is changed to 'office-01'.
>> d) Reboot machine (and run some other scripts)
>> e) Power off the machine. It's done.
>>
>> We are assigning IP addresses by making classes based on host-name option matching.
>>
>> The problem is, that in step b) we have machine with hostname 'golden' and MAC2. So, DHCP server creates a lease for it from dynamic range. Then machine reboots and have hostname 'office-01' and still MAC2 in steps c) and d). Now we need to assign fixed IP by hostname, but there is already lease for it and DHCP server offers this one.
>
> How about having a small pool, and "allow members of golden" where class "golden" is match on hostname="golden" ? Then on first boot, each new machine would get an address from this pool. Once it's changed it's hostname, it will no longer match that class and so will be denied access to that pool - so it will honour other assignments, if you get it all right, this will be your static IP.

We have separated IP pools already. One with public IP adresses for 
office-XX machines and one with private IP addresses for temporary 
in-the-middle-of-cloning machines. The private pool is defined with 
'deny members of "office-01"; deny members od "office-02"; ...'. It is 
hard to maintain. Thanks for the tip to do matching by contraries. Seems 
like good idea.

>> My question is, is there some kind of prefences we could do? I read in manual that priorities are host, class, pool, subnet, shared-network.
>
> Not so much priority, as inheritance. If anything is set in one level, then it will be inherited down the levels until it's either used or over-ridden by being set in a lower level. Thus, for example, you can set name-servers in the global scope and that will apply everywhere - but you could set it again in (say) a subnet declaration and it will apply in that subnet and any pools within it. And you could over-ride it again in a single pool.
>
>
>> And another questions, possibly not so related. We are running separated DHCP server for VDI. And we have a two next DHCP servers in fail-over mode for the rest of the network. The whole network has about 130 subnets and 100 VLANs. We would like to merge VDI DHCP server with the two others. The question is, the host-name matching must work only for VDI VLAN. If I understand manual correctly, class declarations are global. Could it be done by subclasses?
>
> You will need to ensure that your assignment logic supports it. IFF you can be sure that no other host will have a host name "office-nn" then it is sufficient to define a class matching on that. However, since it is easy to set a hostname then someone could upset that.
> Presumably the MAC addresses all fall within one OUI (or a small number of OUIs), so you could extend the matching to that and thus exclude anything not running as a VM with that hypervisor type.

That's the plan. But it is still weak place for security, mainly for 
WiFi access. On the other hand, WiFi is in another VLAN so attacker will 
be without connectivity with such stolen IP.

>> And the last question. How DHCP server handles requests from DHCP relay? In log we can see:
>>
>> - via eth0
>> - via eth1
>> - via 10.70.0.1
>>
>> I guess, that server fetches current eth0 or eth1 IP addresses and match the subnets according to. Is it the same for the relay? Subnet is matched by the relay IP address?
>
> Correct.
> For packets arriving "directly" at the server, it will log "via ethn" and use the subnet(s) defined on that interface to determine an appropriate subnet to consider for address allocation to the client. Where the request is relayed, the relay agent will fill in the GI-Addr (gateway Interface Address) field in the packet and the server will use that. The GI-Addr field *must* be an IP address within the subnet (or shared-network) to which the clients are connected.
>
> For a little light reading :D I strongly recommend The DHCP Handbook by Ralph Droms and Ted Lemon. There's a second edition, but this mostly adds stuff about failover - other than that, the first edition is still very usable. It's both very detailed and very readable - and starts with some history to explain the "WTF did we do it that way" elements of DHCP ! FWIW, both authors are respected in the DHCP field - Ted in particular had a big hand in writing the ISC server, at least the V3 version IIRC, and really knows what he's talking about.

Many thanks for your help and tips!