Description of problem: Libvirt currently blocks NICs with a multicast MAC address (see below) from being plugged on a running VM, essentially not allowing them to be used. Here is the libvirt error when trying to hotplug such a NIC: 2013-09-25 11:12:23.482+0000: 372: debug : virDomainAttachDevice:9624 : dom=0x7f62100029c0, (VM: name=vm1, uuid=4beb8184-3af1-4402-b517-ef9e5336bd25), xml=<interface type="bridge"> <address domain="0x0000" function="0x0" slot="0x04" type="pci" bus="0x00"/> <mac address="01:1a:4a:16:88:5b"/> <model type="e1000"/> <source bridge="rhevm"/> <filterref filter="vdsm-no-mac-spoofing"/> <link state="up"/> </interface> 2013-09-25 11:12:23.483+0000: 372: debug : qemuDomainObjBeginJobInternal:808 : Starting job: modify (async=none) 2013-09-25 11:12:23.483+0000: 372: error : virDomainNetDefParseXML:5041 : XML error: expected unicast mac address, found multicast '01:1a:4a:16:88:5b' The engine, on the other hand, allows entering such addresses and this means that when the the VM containing the NIC is down or when the NIC is unplugged, the NIC can successfully be updated to have a multicast address even though when trying to actually use the NIC later on, libvirt will raise an error. Therefore, validation should be done at the engine to prevent them from being entered in the first place. Doing that will block unwanted scenarios such as https://bugzilla.redhat.com/show_bug.cgi?id=1011887 and uninformative errors when trying to use multicast addresses on a live NIC. Version-Release number of selected component (if applicable): 3.3.0-0.23.master.el6ev How reproducible: 100% Steps to Reproduce: 1. Edit an unplugged NIC and assign it a multicast MAC address. Actual results: The NIC updates successfully. Expected results: An error should prompt a unicast MAC address to be entered instead. The verification should also be done when configuring a MAC address pool range. Additional info: Multi cast MAC address is defined by having the most significant bit of the most significant byte set to 1. In other words it's an address of the form XA:XX:XX:XX:XX:XX where A's parity bit is one, such as 01:1a:4a:16:88:56.
I can set mac range using engine-config: engine-config -s MacPoolRanges=01:1a:4a:16:88:5b-01:1a:4a:16:88:5d when setting this mac range the MacPoolManagerfailed to initializing engine-config should block any mac rage that start with multicast mac address. 2013-10-10 12:03:30,969 ERROR [org.ovirt.engine.core.bll.network.MacPoolManager] (pool-5-thread-1) MacPoolManager(8ded619): Error in initializing MAC Addresses pool manager.: org.ovirt.engine.core.common.errors.VdcBLLException: VdcBLLException: MAC_POOL_INITIALIZATION_FAILED (Failed with error MAC_POOL_INITIALIZATION_FAILED and code 5010) at org.ovirt.engine.core.bll.network.MacPoolManager.initRanges(MacPoolManager.java:118) [bll.jar:] at org.ovirt.engine.core.bll.network.MacPoolManager.initialize(MacPoolManager.java:73) [bll.jar:] at org.ovirt.engine.core.bll.InitBackendServicesOnStartupBean$2.run(InitBackendServicesOnStartupBean.java:68) [bll.jar:] at org.ovirt.engine.core.utils.threadpool.ThreadPoolUtil$InternalWrapperRunnable.run(ThreadPoolUtil.java:71) [utils.jar:] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_25] at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_25] at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_25] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25] at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
(In reply to Meni Yakove from comment #2) > I can set mac range using engine-config: > engine-config -s MacPoolRanges=01:1a:4a:16:88:5b-01:1a:4a:16:88:5d > when setting this mac range the MacPoolManagerfailed to initializing > engine-config should block any mac rage that start with multicast mac > address. > Please note that a given range of 01:00:00:00:00:00-03:00:00:00:00:00:00 is considered legit as it will populate the mac addresses pool with 02:00..00 to 02:FF..FF. The correct behaviour will be extracting the logic of the mac pool manager initialization and invoke it over the given range to assure it produces a valid list of mac addresses.
The fix is not in IS20
rhevm-3.3.0-0.30.beta1.el6ev.noarch
Closing - RHEV 3.3 Released
However, it is necessary to clarify that the “fast fashion” system is not used by the haute couture sector since its elaboration requires different times, raw materials and labor. For example, there are many craftsmen involved in Chanel, they have a strict calendar, they need materials https://failfake.com/pl/