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.
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.
_______________________________________________
Arch mailing list
[email protected]
http://lists.ovirt.org/mailman/listinfo/arch
