(In reply to Nikolai Sednev from comment #0)
> Description of problem:
> HE deployment | MAC Vendor ID is not the same for HE-VM as for the rest of
> the VMs within the host cluster.
> 
> During HE deployment customer offered to choose MAC address for the HE-VM,
> it's possible to chose it randomly from the offered range of 00:16:3E (which
> appears to be vendor ID Xensource, Inc.). After HE deployment completes, all
> default MAC address ranges for the VMs under host cluster appear to be
> 00:1A:4A (which vendor ID is Qumranet Inc.). 
> Please provide default MAC address range for HE-VM during it's deployment
> from the same range of all other VMs after HE is deployed, to be aligned to
> the same vendor ID as Qumranet Inc. 
> 
> Version-Release number of selected component (if applicable):
> [root@alma03 ~]# rpm -qa ovirt* vdsm* libvirt* qemu* sanlock* gluster*
> qemu-kvm-ev-2.1.2-23.el7_1.3.1.x86_64
> glusterfs-geo-replication-3.7.2-3.el7.x86_64
> libvirt-daemon-driver-nwfilter-1.2.8-16.el7_1.3.x86_64
> vdsm-jsonrpc-4.17.0-1054.git562e711.el7.noarch
> glusterfs-client-xlators-3.7.2-3.el7.x86_64
> libvirt-daemon-driver-nodedev-1.2.8-16.el7_1.3.x86_64
> ovirt-engine-sdk-python-3.6.0.0-0.15.20150625.gitfc90daf.el7.centos.noarch
> sanlock-lib-3.2.2-2.el7.x86_64
> vdsm-cli-4.17.0-1054.git562e711.el7.noarch
> glusterfs-cli-3.7.2-3.el7.x86_64
> libvirt-daemon-config-nwfilter-1.2.8-16.el7_1.3.x86_64
> vdsm-4.17.0-1054.git562e711.el7.noarch
> vdsm-xmlrpc-4.17.0-1054.git562e711.el7.noarch
> qemu-img-ev-2.1.2-23.el7_1.3.1.x86_64
> glusterfs-server-3.7.2-3.el7.x86_64
> libvirt-daemon-1.2.8-16.el7_1.3.x86_64
> libvirt-daemon-driver-secret-1.2.8-16.el7_1.3.x86_64
> libvirt-daemon-driver-qemu-1.2.8-16.el7_1.3.x86_64
> ovirt-hosted-engine-setup-1.3.0-0.0.master.20150623153111.git68138d4.el7.
> noarch
> sanlock-python-3.2.2-2.el7.x86_64
> glusterfs-3.7.2-3.el7.x86_64
> libvirt-daemon-driver-interface-1.2.8-16.el7_1.3.x86_64
> vdsm-gluster-4.17.0-1054.git562e711.el7.noarch
> sanlock-3.2.2-2.el7.x86_64
> qemu-kvm-common-ev-2.1.2-23.el7_1.3.1.x86_64
> glusterfs-fuse-3.7.2-3.el7.x86_64
> libvirt-python-1.2.8-7.el7_1.1.x86_64
> libvirt-daemon-kvm-1.2.8-16.el7_1.3.x86_64
> ovirt-vmconsole-1.0.0-0.0.master.20150616120945.gitc1fb2bd.el7.noarch
> vdsm-infra-4.17.0-1054.git562e711.el7.noarch
> vdsm-yajsonrpc-4.17.0-1054.git562e711.el7.noarch
> glusterfs-api-3.7.2-3.el7.x86_64
> libvirt-client-1.2.8-16.el7_1.3.x86_64
> libvirt-daemon-driver-storage-1.2.8-16.el7_1.3.x86_64
> libvirt-daemon-driver-network-1.2.8-16.el7_1.3.x86_64
> ovirt-host-deploy-1.4.0-0.0.master.20150617062825.git06a8f80.el7.noarch
> glusterfs-libs-3.7.2-3.el7.x86_64
> libvirt-lock-sanlock-1.2.8-16.el7_1.3.x86_64
> ovirt-hosted-engine-ha-1.3.0-0.0.master.20150615153650.20150615153645.
> git5f8c290.el7.noarch
> vdsm-python-4.17.0-1054.git562e711.el7.noarch
> Red Hat Enterprise Linux Server release 7.1 (Maipo)
> 
> How reproducible:
> 100%
> 
> Steps to Reproduce:
> 1.Deploy HE on host and get to the default MAC address question, asked
> during HE deployment.
> 2.Check for default MAC address vendor id value at first 3 octets of the MAC
> address.
> 3.Deploy the HE and create VM with default MAC address.
> 4.Compare VM's vendor id with HE-VM's vendor id and realize that they're not
> from the same vendor.
> 
> Actual results:
> Default MAC address range given for HE-VM appears to be from Xen (Citrix)
> instead of Qumranet.
> 
> Expected results:
> Default vendor id during HE deployment should belong to Qumranet vendor id
> MAC address range.
> 
> Additional info:

The issue here is a bit more complicated, as we can't use MAC addresses from our default Qumranet range, unless we'll also implement a mechanism to add/update the chosen MAC into the Engine's DB, to avoid possible address conflicts.

More simpler solution is to use a locally administered MAC range, which still won't avoid the possibility of the conflict if the same MAC address is manually entered by the user for one of the VMs.

Does adding the HE vm resolve this issue, if we assign a MAC from the qumranet range?

Note that MAC range is going to be dropped in engine config.
Martin, is this still needed?

Martin? Roy?

After importing the HE VM, the MAC is unique in the system.

As for the CITRIX vendor - admin can try to edit the VM nic after imported and assign a new nic and MAC.

(In reply to Roy Golan from comment #5)
> After importing the HE VM, the MAC is unique in the system.
> 
> As for the CITRIX vendor - admin can try to edit the VM nic after imported
> and assign a new nic and MAC.

I'm not talking about eporting the HE-VM actually, I'm talking about not relevant MAC vendor ID being assigned to the HE-VM, it should be of qumranet range, not the CITRIX anyway.
So what's the question?

As far as I understood, qumranet range shouldn't be applied anymore to mac pool range, according to bug #1254961. So no need to restrict the mac pool range for Hosted Engine as well. Right?

We now have multiple user-defined mac pools. HOWEVER, it would be nicer to default to the Qumranet range (lacking an explicit request from the user)

(In reply to Dan Kenigsberg from comment #8)
> We now have multiple user-defined mac pools. HOWEVER, it would be nicer to
> default to the Qumranet range (lacking an explicit request from the user)

Ok, this make more sense. Targeting 4.0.

I agree.
However note that the user can always use the MAC he wants, including a CITRIX one so this is not a real issue. Having that said, we will default to a Qumranet MAC once we conclude the hosted engine work for importing the VM.

The current state is that the HE MAC is out of scope and consistent with previous versions. So the chances of collisions are minimal. If we move to use something from our own range (or user defined one), we indeed need to care for other scenarios such as backup/restore and importing VMs which are utilizing addresses from our existing pool.

So thanks for trying but for now I'll close this issue. If you ever have time to properly handle it feel free to reopen.