On Tue, Nov 27, 2012 at 05:12:32PM +0200, Gary Kotton wrote: > On 11/27/2012 05:06 PM, Dan Kenigsberg wrote: > >On Tue, Nov 27, 2012 at 04:43:52PM +0200, Gary Kotton wrote: > >>On 11/27/2012 04:38 PM, Dan Kenigsberg wrote: > >>>On Tue, Nov 27, 2012 at 09:06:14AM -0500, Mike Kolesnik wrote: > >>> > >>>>>ix. I do not udnerstand the race when the VM starts. There is none. > >>>>>When > >>>>>a VM starts it will send a DHCP request. If it does not receive one > >>>>>it > >>>>>will send another after a timeout. Can you please explain the race? > >>>>This is exactly it, the VM might start requesting DHCP lease before it > >>>>was updated in the DHCP server, for us it's a race. > >>>I think the point is that a guest dhclient may give up before Quantum > >>>allocates it an IP. Maybe, due to timing and guests' behavior, the race > >>>would not show up, but it is still there. > >>Yes, this is certainly something that can happen if there are > >>networking problems or if something in the system is broken. How is > >>it done today in oVirt? Does someone has to go and manually update > >>the DHCP server? > >It's not done in oVirt, we want to gain it from Quantum... > >Now you'd have to log into the guest and re-initiate dhclient (or > >restart the guest) after manually configuring the DHCP server. > > Quantum is certainly not perfect. It has a number of shortcomings > but it does work. There are a number of major cloud providers that > are using it and I do not recall them mentioning that they had > problems with the timeout for the DHCP requests. > > My two cents is that oVirt has a to gain by using Quantum. Quantum > is moving fast - at the moment there is a lot of work being done > with the addition of LBaaS. This is currently aimed at the end of > the current release cycle. > > This is a game changer for oVirt.
There is no doubt here about that. oVirt is far from perfect, and as a first modest step towards perfection, we are going to use Quantum's l3 address allocation - we just need learn to tame it. > > > > >>If the messaging is a real concern then you can piggyback to DHCP > >>information on the RPC call to VDSM where the DHCP agent will be > >>running. This will ensure that the information exists in the host > >>file prior to running the VM. On a second read, I'm not sure I understand your suggestion: do you suggest to allocate the address with Quantum, send it to the destination host on top of vmCreate verb, and pass it to a local instance on dnsmasq? This would make Quantum's DHCP agent redundant, as well as the newly-suggested setDHCP verb that's designed to turn it on. Dan. _______________________________________________ Arch mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/arch
