Bug 1193224

Moving this to vdsm, as it takes over network configuration after registration.

It seems that the customer asks to allow mac spoofing on particular VMs/devices. Is that correct? If not, please explain the request better.

This can be implemented today by:
- install vdsm-hook-macspoof on all hosts
- sudo engine-config -s "CustomDeviceProperties={type=interface;prop={$PREVIOUS_PROPERTIES;ifacemacspoof=^(true|false)$}}"
   to enable the ifacemacspoof custom property
- restart engine to make configuration effective
- there's a network you want to connect to, with mac spoofing. Define a vNIC profile on top of it, and set ifacemacspoof=true
- attach the vNIC profile to a vNIC. This vNIC is now allow to carry spoofed traffic


It would be a bit nicer to solve this request natively, with no hooks involved. This could be done by allowing the user to choose a filter name per vNIC profile.

MAC spoofing can already be turned on/off on a per-profile basis, by following Dan's instructions and setting the ifacemacspoof property via the custom properties widget in the vNIC profile dialog.

Please re-open if it turns out I misunderstood your needs and this doesn't satisfy them...

Dan,

While this bug is open for 3.4, my customer got a chance to try your suggestion and it worked until 3.5 came out. Since the he's said this

[In RHEV 3.5] the Syntax seems to be wrong:

[root@engine ~]# engine-config -s "CustomDeviceProperties={type=interface;prop={$PREVIOUS_PROPERTIES;ifacemacspoof=^(true|false)$}}"
Please select a version:
1. 3.0
2. 3.1
3. 3.2
4. 3.3
5. 3.5
6. 3.4
5
Cannot set value {type=interface;prop={;ifacemacspoof=^(true|false)$}} to key CustomDeviceProperties. Invalid syntax, custom device properties specification should conform to \{type=(disk|interface|video|sound|controller|balloon|channel|redir|console|rng|smartcard|watchdog);prop=\{((([a-z_A-Z0-9])+)=(([^;])*)(;(([a-z_A-Z0-9])+)=(([^;])*))*;?)?\}\}[;]?

We updated to RHEV 3.5 now... did the Syntax change?

You should set the value of the PREVIOUS_PROPERTIES shell variable prior to using it

PREVIOUS_PROPERTIES=`engine-config -g CustomDeviceProperties --cver=3.5`

if it ends up empty (as it seems from you comment) you should drop the semicolon following it.

Does this help?

Dan,

Is this the proper way to do this?


[root@engine ~]# PREVIOUS_PROPERTIES=`engine-config -g CustomDeviceProperties --cver=3.5`
[root@engine ~]# engine-config -s "CustomDeviceProperties={type=interface prop={$PREVIOUS_PROPERTIES;ifacemacspoof=^(true|false)$}}"
Please select a version:
1. 3.0
2. 3.1
3. 3.2
4. 3.3
5. 3.5
6. 3.4
5
Cannot set value {type=interface prop={{type=interface;prop={SecurityGroups=^(?:(?:[0-9a-fA-F]{8}-(?:[0-9a-fA-F]{4}-){3}[0-9a-fA-F]{12}, *)*[0-9a-fA-F]{8}-(?:[0-9a-fA-F]{4}-){3}[0-9a-fA-F]{12}|)$}};ifacemacspoof=^(true|false)$}} to key CustomDeviceProperties. Invalid syntax, custom device properties specification should conform to \{type=(disk|interface|video|sound|controller|balloon|channel|redir|console|rng|smartcard|watchdog);prop=\{((([a-z_A-Z0-9])+)=(([^;])*)(;(([a-z_A-Z0-9])+)=(([^;])*))*;?)?\}\}[;]?
[root@engine ~]# engine-config -s "CustomDeviceProperties={type=interface prop={$PREVIOUS_PROPERTIES ifacemacspoof=^(true|false)$}}"
Please select a version:
1. 3.0
2. 3.1
3. 3.2
4. 3.3
5. 3.5
6. 3.4
5
Cannot set value {type=interface prop={{type=interface;prop={SecurityGroups=^(?:(?:[0-9a-fA-F]{8}-(?:[0-9a-fA-F]{4}-){3}[0-9a-fA-F]{12}, *)*[0-9a-fA-F]{8}-(?:[0-9a-fA-F]{4}-){3}[0-9a-fA-F]{12}|)$}} ifacemacspoof=^(true|false)$}} to key CustomDeviceProperties. Invalid syntax, custom device properties specification should conform to \{type=(disk|interface|video|sound|controller|balloon|channel|redir|console|rng|smartcard|watchdog);prop=\{((([a-z_A-Z0-9])+)=(([^;])*)(;(([a-z_A-Z0-9])+)=(([^;])*))*;?)?\}\}[;]?

*** Bug 1255568 has been marked as a duplicate of this bug. ***

This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune with any questions

Verified on 4.0.0.6-0.1.el7ev

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHEA-2016-1743.html