[et-mgmt-tools] [PATCH] [RESEND]Check the making domain's mac address(part 2)
hbrock at redhat.com
Tue Mar 27 15:43:49 UTC 2007
Tatsuro Enokura wrote:
> Hi Hugh
> Hugh Brock wrote:
>> Hi. I had a look at the patch. The idea is OK, but there are two
>> problems: first, I'd rather you not use exceptions for flow control;
>> when you're testing for the mac address, if there's a problem, go
>> straight to the user check rather than going through the whole try:
>> except: sequence.
> Thank you for youre reviewing.
> I rewrite a patch.
>> Second problem is when I try it with a pre-existing
>> mac address from the command line for an inactive, I no longer get a
>> warning of a duplicate (which you set up in your last patch).
> I assume User run various domains with specified time.
> For this case, I just show warning messages only.
> Since user intent to run the same mac address
> with various domain in various time.
> Tatsuro Enokura
Actually now that I have thought some more about this, I don't think we
want to apply it at all.
The current semantics of the --mac flag are as follows:
1. If --mac is specified, attempt to use that address. If it conflicts
with an in-use address, fail with an error
2. If --mac is not specified, choose an unused mac address at random.
You would like to add the case wherein if --mac is specified and
conflicts with an existing mac address, a user can override the
conflict. However, we want operations with virt-install to be scriptable
-- that is, we do not ever want the script to halt waiting for input
unless it is obviously being run interactively. This means that, since a
mac address is never entered at a prompt, we can't put up a warning if
it conflicts. And I don't think we want to change the semantics to
always prompt for a mac address if it is not specified, since most users
aren't going to care what the mac address is anyway.
One way we could address the underlying problem is to change the
mac-address conflict checking code in VirtualNetworkInterface.setup() so
that it prints a warning to the console or logs it, but continues with
the guest creation. I'm fine with this behavior, since it seems
reasonable to me that an installer might want to have multiple inactive
guests with the same mac address. Another alternative would be to fail
if there is an active guest with the same mac address, but only print a
warning (and continue) if there is an inactive guest with the same mac
address. I would take a patch for either scenario.
Red Hat Virtualization Group http://redhat.com/virtualization
Hugh Brock | virt-manager http://virt-manager.org
hbrock at redhat.com | virtualization library http://libvirt.org
More information about the et-mgmt-tools