On Thu, Jun 19, 2014 at 12:34:51PM +0100, Dan Kenigsberg wrote: I've posted a hook like that to http://gerrit.ovirt.org/#/c/29093/1 Maybe you can try it out, by placing http://gerrit.ovirt.org/#/c/29093/1/vdsm_hooks/noipspoof/noipspoof.py on your /usr/libexec/vdsm/hooks/before_device_create on each of your hosts, and setting a custom property named "noipspoof" to a list of valid IP addresses. Please report if it does what it should. It would obviously be nicer if we integrate this with cloud-init, so that each VM would have its list of valid addresses defined once. Care to open an RFE? Regards, Dan.

Am 24.06.2014 11:52, schrieb Punit Dambiwal: Imho you can't force the vm to not spin it's inside network interface up with a certain IP. What you _can_ (and should) prevent is to allow packets from this spoofed ip to access your network. this is, what the filter no-ip-spoofing does, see the docs here: http://libvirt.org/formatnwfilter.html#nwfexamples it prevents sending spoofed packages from inside the vm by not allowing them on the virtual integrated libvirt switch on your host (which runs the vm). this might look a little different, depending on your network setup (bonding, bridges, vlans). HTH -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen

Hi Dan, I try the following way :- 1. I placed your script in the following location :- /usr/libexec/vdsm/hooks/before_device_create/50_noipspoof & /usr/libexec/vdsm/hooks/before_nic_hotplug/50_noipspoof 2. Then run this command on the ovirt-engine server (engine-config -s "UserDefinedVMProperties=noipspoof=^[0-9.]*$") 3. After that stop the VM and set a custom property named "noipspoof" with ip 10.10.10.6. 4. Run the VM and login via ssh,configure another ethernet with eth0:0 with the ip address 10.10.10.9 5. From another VM with ip 10.10.10.5 i can able to ping 10.10.10.9.... One strange thing is in VM xml still the filter is "vdsm-no-mac-spoofing" instead of "noipspoof" ---------------- <interface type='bridge'> <mac address='00:1a:4a:81:80:09'/> <source bridge='private'/> <target dev='vnet0'/> <model type='virtio'/> <filterref filter='vdsm-no-mac-spoofing'/> <link state='up'/> <alias name='net0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/ ---------------- Please let me know if i am wrong here.... [image: Inline image 1] On Tue, Jun 24, 2014 at 8:06 PM, Dan Kenigsberg <danken(a)redhat.com&gt; wrote:

On Wed, Jun 25, 2014 at 10:16:12AM +0800, Punit Dambiwal wrote: I can try to help you debug the issue. Could you attach vdsm.log from the vmCreate command to the place where the VM turns to "Up"? Can you verify that /usr/libexec/vdsm/hooks/before_device_create/50_noipspoof is executable to the vdsm user? Dan.

On Wed, Jun 25, 2014 at 06:03:50PM +0800, Punit Dambiwal wrote: I see no reference there to /usr/libexec/vdsm/hooks/before_device_create (but other hook scripts are mentioned). Could you do # su - vdsm -s /bin/bash $ ls -l /usr/libexec/vdsm/hooks/before_device_create so we can confirm that the scripts exists and are executable?

Well this is strange, and this should not be the reason but can you attach a ".py" ending to the file names (maybe vdsm performs some strange checks)? your permissions look good. the only other thing I can think of are selinux restrictions, can you check them with: #this gives you the actual used selinux security level: getenforce :this gives you the selinux attributes for the folder: ls -lZ /usr/libexec/vdsm/hooks/before_device_create I first thought it might be related to vdsms sudoers rights but a plain python script should be executed without modification to the sudoers config. HTH Am 26.06.2014 06:22, schrieb Punit Dambiwal: -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen

Hi Sven, I already give the sudo user permission to VDSM user... Yes..after VDSM restart i can see this hook in host tab....I will test it again and udpate you guys if still not solve.... On Thu, Jun 26, 2014 at 4:03 PM, Antoni Segura Puimedon <asegurap(a)redhat.com

----- Original Message ----- Did you try to disable SELinux with "setenforce 0" to see if the problem is one of secure contexts?

Hi, I found below messages in the audit log :- [root@gfs1 ~]# grep "avc" /var/log/audit/audit.log type=AVC msg=audit(1403834461.442:266685): avc: denied { read } for pid=27958 comm="logrotate" name="core" dev=dm-0 ino=789758 scontext=system_u:system_r:log rotate_t:s0-s0:c0.c1023 tcontext=system_u:object_r:virt_cache_t:s0 tclass=dir type=AVC msg=audit(1403835901.532:266865): avc: denied { read } for pid=29746 comm="xz" name="online" dev=sysfs ino=23 scontext=system_u:system_r:logrotate_t :s0-s0:c0.c1023 tcontext=system_u:object_r:sysfs_t:s0 tclass=file type=AVC msg=audit(1403836508.226:266868): avc: denied { signal } for pid=353 7 comm="sanlock-helper" scontext=unconfined_u:system_r:sanlock_t:s0-s0:c0.c1023 tcontext=unconfined_u:system_r:virtd_t:s0-s0:c0.c1023 tclass=process type=AVC msg=audit(1403838061.918:266965): avc: denied { read } for pid=32528 comm="logrotate" name="core" dev=dm-0 ino=789758 scontext=system_u:system_r:log rotate_t:s0-s0:c0.c1023 tcontext=system_u:object_r:virt_cache_t:s0 tclass=dir type=AVC msg=audit(1403841661.051:267604): avc: denied { read } for pid=3256 comm="logrotate" name="core" dev=dm-0 ino=789758 scontext=system_u:system_r:logr otate_t:s0-s0:c0.c1023 tcontext=system_u:object_r:virt_cache_t:s0 tclass=dir type=AVC msg=audit(1403841661.053:267605): avc: denied { read } for pid=3257 comm="xz" name="online" dev=sysfs ino=23 scontext=system_u:system_r:logrotate_t: s0-s0:c0.c1023 tcontext=system_u:object_r:sysfs_t:s0 tclass=file type=AVC msg=audit(1403845261.394:271326): avc: denied { read } for pid=6791 comm="logrotate" name="core" dev=dm-0 ino=789758 scontext=system_u:system_r:logr otate_t:s0-s0:c0.c1023 tcontext=system_u:object_r:virt_cache_t:s0 tclass=dir type=AVC msg=audit(1403848861.538:271797): avc: denied { read } for pid=9269 comm="logrotate" name="core" dev=dm-0 ino=789758 scontext=system_u:system_r:logr otate_t:s0-s0:c0.c1023 tcontext=system_u:object_r:virt_cache_t:s0 tclass=dir type=AVC msg=audit(1403852461.654:272828): avc: denied { read } for pid=12222 comm="logrotate" name="core" dev=dm-0 ino=789758 scontext=system_u:system_r:log rotate_t:s0-s0:c0.c1023 tcontext=system_u:object_r:virt_cache_t:s0 tclass=dir type=AVC msg=audit(1403852998.237:272831): avc: denied { signal } for pid=353 7 comm="sanlock-helper" scontext=unconfined_u:system_r:sanlock_t:s0-s0:c0.c1023 tcontext=unconfined_u:system_r:virtd_t:s0-s0:c0.c1023 tclass=process type=AVC msg=audit(1403856061.898:273118): avc: denied { read } for pid=16215 comm="logrotate" name="core" dev=dm-0 ino=789758 scontext=system_u:system_r:log rotate_t:s0-s0:c0.c1023 tcontext=system_u:object_r:virt_cache_t:s0 tclass=dir type=AVC msg=audit(1403859661.098:273934): avc: denied { read } for pid=19991 comm="logrotate" name="core" dev=dm-0 ino=789758 scontext=system_u:system_r:log rotate_t:s0-s0:c0.c1023 tcontext=system_u:object_r:virt_cache_t:s0 tclass=dir type=AVC msg=audit(1403863261.394:276053): avc: denied { read } for pid=24345 comm="logrotate" name="core" dev=dm-0 ino=789758 scontext=system_u:system_r:log rotate_t:s0-s0:c0.c1023 tcontext=system_u:object_r:virt_cache_t:s0 tclass=dir [root@gfs1 ~]# On Fri, Jun 27, 2014 at 5:35 PM, Sven Kieske <S.Kieske(a)mittwald.de&gt; wrote:

On Fri, Jun 27, 2014 at 05:07:56PM +0800, Punit Dambiwal wrote: <snip> yep, the hook script did not come into action. and I am still at the dark regarding what could cause that. Would you repeat the following line, as root and as vdsm user? $ cd /usr/share/vdsm; python -c 'import hooks;print hooks._scriptsPerDir("before_device_create")'

On Fri, Jun 27, 2014 at 05:36:49PM +0800, Punit Dambiwal wrote: very odd. could you try again and attach a fresh log of the vmCreate flow? Maybe you could add a sys.stderr.write('%s' % os.environ) line in the main() function of the script just to see if it's ever called?

On Mon, Jun 30, 2014 at 10:11:21AM +0800, Punit Dambiwal wrote: And now, the log does not mention any hook at all. Have you removed the macspoof hook which you had there before? How many hosts do you have? Do they have the same set of installed hooks on them all? Dan.

On Mon, Jun 30, 2014 at 06:17:25PM +0800, Punit Dambiwal wrote: No, as long as you start the VM on the specific host you should be fine. The fact that the macspoof hook disappeared made me worry that you have not. Unfortunately, I have no more guesses why this specific hook would not run when it should. What happens when you put a silly script instead, that only does echo hello world > /dev/stderr can you see a trace of it in vdsm.log? Remind me, does PYTHONPATH=/usr/share/vdsm /usr/libexec/vdsm/hooks/before_device_create/50_noipspoof.py --test work for you?

On Wed, Jul 02, 2014 at 09:55:19AM +0800, Punit Dambiwal wrote: The .py extension is my typo; I'm shooting at the dark, trying to guess why the script does not even attempt to be run for you.

Hi Dan, If i use openstack neutron and integrate with ovirt....can it help to prevent the ip spoof ?? If yes...is there any good howto for install the neutron & integrate neutron with ovirt ?? Thanks, Punit On Wed, Jul 2, 2014 at 4:55 PM, Punit Dambiwal <hypunit(a)gmail.com&gt; wrote:

Hi Dan, The permission looks ok... [root@gfs1 ~]# su - vdsm -s /bin/bash -bash-4.1$ ls -l /usr/libexec/vdsm/hooks/before_device_create total 8 -rwxr-xr-x. 1 root root 1702 Jun 10 05:25 50_macspoof -rwxr-xr-x. 1 root root 2490 Jun 23 17:47 50_noipspoof -bash-4.1$ exit logout [root@gfs1 ~]# But the strange thing is noipspoof hook not display in the host hooks windows....please check the attachment. On Wed, Jun 25, 2014 at 6:30 PM, Dan Kenigsberg <danken(a)redhat.com&gt; wrote:

Hi Jure, It's ok....but what about if user will spoof the ip on the eth0:0....then the mac address will be same as eth0 ?? how we can control this ?? Thanks, Punit D On Wed, Jul 9, 2014 at 3:38 PM, Jure Kranjc <jure.kranjc(a)arnes.si&gt; wrote: