On 09/05/2012 07:55 AM, Gene Czarcinski wrote:
On 09/04/2012 11:12 AM, Eric Blake wrote:
On 08/22/2012 11:47 AM, Eric Blake wrote:
On 08/22/2012 11:39 AM, Eric Blake wrote:
On 08/22/2012 10:59 AM, Gene Czarcinski wrote:
As I said in a previous message, dnsmasq is forwarding a number of queries upstream that should not be done. There still remains an MX query for a plain name with no domain specified that will be forwarded is dnsmasq has --domain=xxx --local=/xxx/ specified. This does not happen with no domain name and --local=// ... not a libvirt problem.
ACK and pushed with the above tweak, and with adding you to AUTHORS (let us know if you prefer any other spelling or email address; the file is in UTF-8). Oh, and now that I've already pushed, I have a high-level question: what is the minimum version of 'dnsmasq' that supports the command-line syntax that this patch introduces?
+--local=// --domain-needed --filterwin2k \
If older dnsmasq doesn't recognize --local=// or the new --domain-needed or --filterwin2k options, then we either need to make this code conditional based on probing 'dnsmasq --help' at startup, or else change the spec file to require a larger minimum version of dnsmasq (we already require 2.41 for other reasons). Just as I feared, we introduced a regression:
https://bugzilla.redhat.com/show_bug.cgi?id=854137
Apparently, --filterwin2k disables features needed by Windows guests. Gene, what is the benefit vs. cost of adding this flag? I'm trying to figure out whether we need to expose it as something user-configurable, or whether we should just revert back to the pre-patch version that did not supply that option.
I already had some second thoughts about --filterwin2k but you had pushed it. "--filterwin2k" should be removed.
Yes, as rare as dialup lines are these days, I think it's highly unlikely that anyone running a virt host will be connected to the rest of the network in a way which will require bringing up a dialup network connection in order to send a packet to a domain controller. So, I don't think we should clutter the XML with such a specific option that will in all likelyhood never be used.