Description of problem: Preview and Commit of VM, when one of its NIC has MAC, that is already used by another VM succeeds. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Create snapshot for VM 2. Create another VM with NIC's MAC equal to the VM you performed snapshot before 3. Preview and Commit the snapshot VM Actual results: Restoring of the VM succeeds with the MAC that is already used Expected results: Restoring should fail or error message with request to change MAC should appear Additional info: The BZ is similar in behaviour to BZ 872100, when you could import VM with already existing MAC
I am not sure I agree restore should fail. If we are restoring a VM and it's MAC (as kept in the snapshot) is already in use by another VM, we should issue a warning/Error to the audit log but the user can not change/edit a snapshot configuration before the restore succeed. Failing the restore leaves the user with no real option. I suggest we'll be able to restore the VM and maybe block starting the VM if it has MAC address that is already in use according to the blocking duplicate MAC policy configured in the setup. This option means that we need to validate before starting a VM if there is a VM that is currently using this MAC in the setup and if there is one block this VM from starting. Taking this to the next level is to block starting the VM only if there is another *running* VM that uses this MAC. simon, input on the above?
(In reply to comment #1) >This option means that we need to validate before starting a VM if there is a VM that is currently using this MAC in the setup and if there is one block this VM from starting. >Taking this to the next level is to block starting the VM only if there is another *running* VM that uses this MAC. > simon, input on the above? +1 I think we need it anyhow. Consider the case where dup MAC address where allowed and it caused so much trouble that the customer turns it back off. What happens to all of these that were already configured with dups? P.S. There may be multiple causes for a snapshot to have an existing MAC, the one I'm worried about is this: 1. A VM has mac A 2. User takes snapshots 3. User deletes the NIC - Will the MAC return to the pool? if so then.. ..4. User creates a new VM, this VM reuses no MAC A Now you unintentionally created a scenario where you have duplicate MAC in the system - This should be prevented by not releasing a MAC that exists in a snapshot. Livnat can this happen? If so let's open another BZ for it.
> P.S. > There may be multiple causes for a snapshot to have an existing MAC, the one > I'm worried about is this: > 1. A VM has mac A > 2. User takes snapshots > 3. User deletes the NIC - Will the MAC return to the pool? if so then.. > ..4. User creates a new VM, this VM reuses no MAC A > > Now you unintentionally created a scenario where you have duplicate MAC in > the system - This should be prevented by not releasing a MAC that exists in > a snapshot. > > Livnat can this happen? If so let's open another BZ for it. This is the scenario we had in mind when reporting this bug, a MAC is used in a snapshot for whatever reason and not in the current active configuration of the VM and when previewing the snapshot we get collision. but if you really want we caught another problematic scenario in the snapshot preview area - bug 873338 :) I don't like the option of not releasing a MAC that is used in a snapshot, when taking a snapshot the MACS in that snapshot are not necessarily in use I see no reason not to release unused MACs back to the pool. Having MAC not in use and not releasing it back to the pool can cause anomaly in the MACs allocation in the system. In addition of the fact that I think this is not the best approach I also think on the implementation complication this hides: - Whenever a nic is removed from the VM and we want to release the MAC back to the pool we need to process all it's snapshots to see if it is not in used in one of them. - or another implementation option is that on each snapshot manipulation like remove, create, collapse we'll need to add MAC release logic You seems to agree that we need to block starting a VM if there is already a running VM using the same MAC address as you wrote this is useful for other use cases. We can make this RFE and prioritize it for future version. If you agree I'll change this to RFE and fix the title to reflect that.
Summary: The original problem reported in this bug is indeed a problem, currently the engine issues an audit log warning but we all agree this is not enough. I changed the title of the bug to reflect the RFE representing the solution for this bug and this is: blocking VM from starting if there is another running VM that uses one of it's MAC addresses and the policy in the config indicates we should block duplicate MAC addresses.
*** This bug has been marked as a duplicate of bug 873338 ***