Re: [Users] Otopi pre-seeded answers and firewall settings
From: Giuseppe Ragusa giuseppe.rag...@hotmail.com To: Yedidyah Bar David d...@redhat.com Cc: Users@ovirt.org users@ovirt.org Sent: Wednesday, March 26, 2014 12:09:44 AM Subject: RE: [Users] Otopi pre-seeded answers and firewall settings Hi Didi, I can confirm that using both an ovhe-answers.conf directive: OVEHOSTED_NETWORK/firewallManager=str:nonexistent and an /etc/ovirt-host-deploy.conf.d/99-prevent-iptables.conf with: [environment:enforce] NETWORK/iptablesEnable=bool:False results in ovirt-hosted-engine-setup --config-append=ovhe-answers.conf leaving iptables rules untouched while adding the second hypervisor host to an already deployed self-hosted-engine with one physical host. Thanks for the report! As I said, I am not sure this is a perfect solution, because now the engine thinks it updated iptables where in practice it didn't. Many thanks again, Giuseppe PS: is there any difference in using ovirt-hosted-engine-setup vs. hosted-engine --deploy ? No. -- Didi ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] Otopi pre-seeded answers and firewall settings
From: Giuseppe Ragusa giuseppe.rag...@hotmail.com To: Yedidyah Bar David d...@redhat.com Cc: Users@ovirt.org users@ovirt.org Sent: Tuesday, March 25, 2014 11:49:36 PM Subject: RE: [Users] Otopi pre-seeded answers and firewall settings Hi Didi, many thanks for your invaluable help! I'll try your suggestion (/etc/ovirt-host-deploy.conf.d/99-prevent-iptables.conf) asap and then I will report back. By the way: I have a really custom iptables setup (multiple separated networks on hypervisor hosts), so I suppose it's best to hand tune firewall rules and then leave them alone (I pre-configure them, so the setup procedure won't be impeded in its communication needs anyway AND I will always guarantee the most stringent filtering possible with default deny ecc.). I now asked Sandro and he told me the obvious: In the New Host form there is a checkbox for that :-) In hosted-engine we do not support that, it's always set - ' override_iptables=True ' in [1]. You can open a bug if you want, to make this configurable. It might make sense to use the value input in the question about iptables, but these are different issues. [1] http://gerrit.ovirt.org/gitweb?p=ovirt-hosted-engine-setup.git;a=blob;f=src/plugins/ovirt-hosted-engine-setup/engine/add_host.py -- Didi ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] Otopi pre-seeded answers and firewall settings
I really don't get why many people always ask others to open BZ, if you could just do it yourself. It doesn't take much time, less than writing a Mail to explain to someone to report a BZ. So here it is: https://bugzilla.redhat.com/show_bug.cgi?id=1080823 Am 26.03.2014 08:51, schrieb Yedidyah Bar David: You can open a bug if you want, to make this configurable. -- 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 ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] Otopi pre-seeded answers and firewall settings
From: s.kie...@mittwald.de To: users@ovirt.org Date: Wed, 26 Mar 2014 08:23:05 + Subject: Re: [Users] Otopi pre-seeded answers and firewall settings I really don't get why many people always ask others to open BZ, if you could just do it yourself. It doesn't take much time, less than writing a Mail to explain to someone to report a BZ. I suppose that proper bug tracking management should in general keep involved the real stakeholders, ie the users that have experienced the problems first hand, so that any further action can keep them in the feedback loop with real use cases, reminders to developers etc. and this seems particularly appropriate for open source projects with developers that devote voluntary work (Sven: try not to think of all those nice @redhat.com addresses and RHEV references ; ) On the other hand I also understand that this is a particularly straightforward RFE with no (apparent) need for logs, traces etc. but the established workflow always wins :) and proves real user request to managers :)) So here it is: https://bugzilla.redhat.com/show_bug.cgi?id=1080823 Many thanks Sven (I actually have a bad track record as a Bugzilla reporter... almost always dismissed ; ) Regards, Giuseppe Am 26.03.2014 08:51, schrieb Yedidyah Bar David: You can open a bug if you want, to make this configurable. -- 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 ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] Otopi pre-seeded answers and firewall settings
From: Giuseppe Ragusa giuseppe.rag...@hotmail.com To: Yedidyah Bar David d...@redhat.com Cc: Users@ovirt.org users@ovirt.org Sent: Tuesday, March 25, 2014 1:53:20 AM Subject: RE: [Users] Otopi pre-seeded answers and firewall settings Hi Didi, I found the references to NETWORK/iptablesEnable in my engine logs (/var/log/ovirt-engine/host-deploy/ovirt-*.log), but it didn't seem to work after all. Full logs attached. I resurrected my Engine by rebooting the (still only) host, then restarting ovirt-ha-agent (at startup the agent failed while trying to launch vdsm, but I found vdsm running and so tried manually...). OK, so it's host-deploy that's doing that. But it's not host-deploy itself - it's the engine that is talking to it, asking it to configure iptables. I don't know how to make the agent don't do that. I searched a bit the sources (which I don't know) and didn't find a simple way. You can, however, try to override this by: # mkdir -p /etc/ovirt-host-deploy.conf.d # echo '[environment:enforce]' /etc/ovirt-host-deploy.conf.d/99-prevent-iptables.conf # echo 'NETWORK/iptablesEnable=bool:False' /etc/ovirt-host-deploy.conf.d/99-prevent-iptables.conf Never tried that, and not sure it's recommended - if it does work, it means that host-deploy will not update iptables, but the engine will think it did. So it's better to find a way to make the engine not do that. Or, better yet, that you'll explain why you need this and somehow make the engine do what you want... -- Didi ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] Otopi pre-seeded answers and firewall settings
Hi Didi, many thanks for your invaluable help! I'll try your suggestion (/etc/ovirt-host-deploy.conf.d/99-prevent-iptables.conf) asap and then I will report back. By the way: I have a really custom iptables setup (multiple separated networks on hypervisor hosts), so I suppose it's best to hand tune firewall rules and then leave them alone (I pre-configure them, so the setup procedure won't be impeded in its communication needs anyway AND I will always guarantee the most stringent filtering possible with default deny ecc.). Many thanks again, Giuseppe Date: Tue, 25 Mar 2014 04:05:33 -0400 From: d...@redhat.com To: giuseppe.rag...@hotmail.com CC: users@ovirt.org Subject: Re: [Users] Otopi pre-seeded answers and firewall settings From: Giuseppe Ragusa giuseppe.rag...@hotmail.com To: Yedidyah Bar David d...@redhat.com Cc: Users@ovirt.org users@ovirt.org Sent: Tuesday, March 25, 2014 1:53:20 AM Subject: RE: [Users] Otopi pre-seeded answers and firewall settings Hi Didi, I found the references to NETWORK/iptablesEnable in my engine logs (/var/log/ovirt-engine/host-deploy/ovirt-*.log), but it didn't seem to work after all. Full logs attached. I resurrected my Engine by rebooting the (still only) host, then restarting ovirt-ha-agent (at startup the agent failed while trying to launch vdsm, but I found vdsm running and so tried manually...). OK, so it's host-deploy that's doing that.But it's not host-deploy itself - it's the engine that is talking to it, asking it to configure iptables.I don't know how to make the agent don't do that. I searched a bit the sources (which I don't know)and didn't find a simple way. You can, however, try to override this by:# mkdir -p /etc/ovirt-host-deploy.conf.d# echo '[environment:enforce]' /etc/ovirt-host-deploy.conf.d/99-prevent-iptables.conf# echo 'NETWORK/iptablesEnable=bool:False' /etc/ovirt-host-deploy.conf.d/99-prevent-iptables.conf Never tried that, and not sure it's recommended - if it does work, it means that host-deploy will notupdate iptables, but the engine will think it did. So it's better to find a way to make the engine not dothat. Or, better yet, that you'll explain why you need this and somehow make the engine do what you want...-- Didi ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] Otopi pre-seeded answers and firewall settings
Hi Joshua, many thanks for your suggestion which I suppose would work perfectly, but I actually want iptables (CentOS 6.5 here, so no firewalld) rules in place all the time, but only MY OWN iptables rules ; Regards, Giuseppe Date: Tue, 25 Mar 2014 18:04:04 -0400 Subject: Re: [Users] Otopi pre-seeded answers and firewall settings From: j...@wrale.com To: giuseppe.rag...@hotmail.com Perhaps you could add the iptables and firewalld packages to yum.conf as excludes. I don't know if this would fail silently, but if so, the engine installer would never know. Thanks, Joshua On Tue, Mar 25, 2014 at 5:49 PM, Giuseppe Ragusa giuseppe.rag...@hotmail.com wrote: Hi Didi, many thanks for your invaluable help! I'll try your suggestion (/etc/ovirt-host-deploy.conf.d/99-prevent-iptables.conf) asap and then I will report back. By the way: I have a really custom iptables setup (multiple separated networks on hypervisor hosts), so I suppose it's best to hand tune firewall rules and then leave them alone (I pre-configure them, so the setup procedure won't be impeded in its communication needs anyway AND I will always guarantee the most stringent filtering possible with default deny ecc.). Many thanks again, Giuseppe Date: Tue, 25 Mar 2014 04:05:33 -0400 From: d...@redhat.com To: giuseppe.rag...@hotmail.com CC: users@ovirt.org Subject: Re: [Users] Otopi pre-seeded answers and firewall settings From: Giuseppe Ragusa giuseppe.rag...@hotmail.com To: Yedidyah Bar David d...@redhat.com Cc: Users@ovirt.org users@ovirt.org Sent: Tuesday, March 25, 2014 1:53:20 AM Subject: RE: [Users] Otopi pre-seeded answers and firewall settings Hi Didi, I found the references to NETWORK/iptablesEnable in my engine logs (/var/log/ovirt-engine/host-deploy/ovirt-*.log), but it didn't seem to work after all. Full logs attached. I resurrected my Engine by rebooting the (still only) host, then restarting ovirt-ha-agent (at startup the agent failed while trying to launch vdsm, but I found vdsm running and so tried manually...). OK, so it's host-deploy that's doing that.But it's not host-deploy itself - it's the engine that is talking to it, asking it to configure iptables.I don't know how to make the agent don't do that. I searched a bit the sources (which I don't know) and didn't find a simple way. You can, however, try to override this by:# mkdir -p /etc/ovirt-host-deploy.conf.d# echo '[environment:enforce]' /etc/ovirt-host-deploy.conf.d/99-prevent-iptables.conf # echo 'NETWORK/iptablesEnable=bool:False' /etc/ovirt-host-deploy.conf.d/99-prevent-iptables.conf Never tried that, and not sure it's recommended - if it does work, it means that host-deploy will not update iptables, but the engine will think it did. So it's better to find a way to make the engine not dothat. Or, better yet, that you'll explain why you need this and somehow make the engine do what you want... -- Didi ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] Otopi pre-seeded answers and firewall settings
From: Giuseppe Ragusa giuseppe.rag...@hotmail.com To: Users@ovirt.org users@ovirt.org Sent: Sunday, March 23, 2014 10:44:02 PM Subject: [Users] Otopi pre-seeded answers and firewall settings Hi all, I'm trying to automate as much as possible of ovirt-hosted-engine-setup and engine-setup by means of otopi answer files passed in using --config-append=filename.conf. I succeded in forcing engine-setup to leave my iptables settings alone with: OVESETUP_CONFIG/firewallManager=str:iptables OVESETUP_CONFIG/updateFirewall=bool:False Right. but ovirt-hosted-engine-setup still modified my iptables settings even with the following options: OVEHOSTED_NETWORK/firewallManager=str:iptables Actually I do not think we provide in hosted-engine deploy means to disable this as we do in engine-setup. If you carefully read the code you see that you can make it do nothing by setting this to a non-existent manager, e.g.: OVEHOSTED_NETWORK/firewallManager=str:nonexistent OVEHOSTED_NETWORK/iptablesEnable=bool:False Where did you get this from? Can't find it in the code. Maybe I used the wrong option (deduced by looking inside source code). Does anybody have any hint/suggestion? The above should prevent 'hosted-engine --deploy' from configuring iptables on the host, and to prevent 'engine-setup' from configuring iptables on the VM. Later, the engine runs 'ovirt-host-deploy' which connects to the host and configures there stuff - some by itself, some using vdsm, and some sent through them directly from the engine. This is a process I know less... You can look at and/or post more relevant logs - /var/log/ovirt-engine/host-deploy/* , /var/log/ovirt-engine/*.log from the engine VM and /var/log/vdsm/* from the host, and also check iptables configuration at various stages - during hosted-engine deploy but before connecting to the engine, after, etc. -- Didi ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] Otopi pre-seeded answers and firewall settings
Hi Didi, Date: Mon, 24 Mar 2014 03:36:32 -0400 From: d...@redhat.com To: giuseppe.rag...@hotmail.com CC: users@ovirt.org Subject: Re: [Users] Otopi pre-seeded answers and firewall settings From: Giuseppe Ragusa giuseppe.rag...@hotmail.com To: Users@ovirt.org users@ovirt.org Sent: Sunday, March 23, 2014 10:44:02 PM Subject: [Users] Otopi pre-seeded answers and firewall settings Hi all, I'm trying to automate as much as possible of ovirt-hosted-engine-setup and engine-setup by means of otopi answer files passed in using --config-append=filename.conf. I succeded in forcing engine-setup to leave my iptables settings alone with: OVESETUP_CONFIG/firewallManager=str:iptables OVESETUP_CONFIG/updateFirewall=bool:False Right. but ovirt-hosted-engine-setup still modified my iptables settings even with the following options: OVEHOSTED_NETWORK/firewallManager=str:iptables Actually I do not think we provide in hosted-engine deploy means to disable this as we do in engine-setup. If you carefully read the code you see that you can make it do nothing by setting this to a non-existent manager, e.g.: OVEHOSTED_NETWORK/firewallManager=str:nonexistent I will try this asap (reinstalling from scratch using latest 3.4 snapshot packages + latest GlusterFS 3.5 nightly) and will report back. OVEHOSTED_NETWORK/iptablesEnable=bool:False Where did you get this from? Can't find it in the code. Nor do I anymore... it must have been my fault, sorry for the confusion Maybe I used the wrong option (deduced by looking inside source code). Does anybody have any hint/suggestion? The above should prevent 'hosted-engine --deploy' from configuring iptables on the host, and to prevent 'engine-setup' from configuring iptables on the VM. Later, the engine runs 'ovirt-host-deploy' which connects to the host and configures there stuff - some by itself, some using vdsm, and some sent through them directly from the engine. This is a process I know less... The timestamp on the saved/modified iptables files suggests something happening right at the end of setup (when Self-Hosted-Engine adds/registers host). You can look at and/or post more relevant logs - /var/log/ovirt-engine/host-deploy/* , /var/log/ovirt-engine/*.log from the engine VM and /var/log/vdsm/* from the host, and also check iptables configuration at various stages - during hosted-engine deploy but before connecting to the engine, after, etc. -- Didi /var/log/vdsm/* on host contain no references to iptables I will check on Engine logs as soon as I can start it up again (GlusterFS-based NFS keeps crashing, maybe for OOM/leakage). Many thanks for your help, Giuseppe ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] Otopi pre-seeded answers and firewall settings
Giuseppe, et. al
I gave up on my six-server hosted engine install, partly for this reason.
In addition to this problem, I found that I couldn't use a bridge of my own
naming. Then, trying to associate interfaces with bridges in the web
interface, my hand-tuned bridges were fatally clobbered. Like, the files I
wrote by hand in /etc/sysconfig/ifcfg-*, bridges, and interfaces (some with
VLANs) alike. And other things... like the Westmere vs. Ivy Bridge thing.
Anyway, I think what's happening to your install is that iptables on the
host is getting clobbered by the automatic install that happens when the
hosted-engine setup script finally contacts the engine the for the first
time. I'm not sure how to keep this from happening, but it's a place to
start. And I think it's the reason your setting False didn't help. By the
way, it took a two hour test for me to learn that even removing the
/etc/sysconfig/iptables file AND stopping AND disabling iptables via
systemctl on both host and engine did nothing to combat this behavior.
Back when I set up 3.0, I saw similar behavior. At that time though, the
iptables thing wasn't fatal. I observed here that this overwriting and
enabling/starting of iptables causes the very lest part of the
hosted-engine setup script to fail miserably. As a result of the engine
not being able to contact the host at the end of its install phase, the
H/A configuration is never done. This is my theory, anyway.
I think oVirt should leave the firewall _completely_ alone and just
document what ports should be open. I don't think we need that special
line at the bottom of /etc/sysconfig/iptables oVirt puts in there. I'll
stop rambling now. :-) I like oVirt, but getting so far into this that I
have a have two hour turnaround every time I want to test a minor tweak is
just too much. I think this will get better in time, I hope. At that
time, maybe I'll try again.
Here's what libvirt has to say about iptables vs. bridges:
The final step is to disable netfilter on the bridge:
# cat /etc/sysctl.conf EOF
net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-call-iptables = 0
net.bridge.bridge-nf-call-arptables = 0
EOF
# sysctl -p /etc/sysctl.conf
It is recommended to do this for performance and security reasons. See Fedora
bug #512206 https://bugzilla.redhat.com/512206. Alternatively you can
configure iptables to allow all traffic to be forwarded across the bridge:
# echo -I FORWARD -m physdev --physdev-is-bridged -j ACCEPT
/etc/sysconfig/iptables-forward-bridged
# lokkit --custom-rules=ipv4:filter:/etc/sysconfig/iptables-forward-bridged
# service libvirtd reload
source:
http://wiki.libvirt.org/page/Networking#Creating_network_initscripts
You might be interested to know that you can pre-populate vm.conf.in in
/usr/share, before the install. Here was mine:
vmId=@VM_UUID@
memSize=@MEM_SIZE@
display=@CONSOLE_TYPE@
devices={index:2,iface:ide,address:{ controller:0, target:0,unit:0,
bus:1,
type:drive},specParams:{},readonly:true,deviceId:@CDROM_UUID@,path:@CDROM@,device:cdrom,shared:false,type:disk@BOOT_CDROM@}
devices={index:0,iface:virtio,format:raw,poolID:@SP_UUID@,volumeID:@VOL_UUID@,imageID:@IMG_UUID@,specParams:{},readonly:false,domainID:@SD_UUID@,optional:false,deviceId:@IMG_UUID@,address:{bus:0x00,
slot:0x06, domain:0x, type:pci,
function:0x0},device:disk,shared:exclusive,propagateErrors:off,type:disk@BOOT_DISK@}
devices={device:scsi,model:virtio-scsi,type:controller}
devices={device:console,specParams:{},type:console,deviceId:@CONSOLE_UUID@,alias:console0}
vmName=@NAME@
spiceSecureChannels=smain,sdisplay,sinputs,scursor,splayback,srecord,ssmartcard,susbredir
smp=@VCPUS@
cpuType=@CPU_TYPE@
emulatedMachine=@EMULATED_MACHINE@
devices={nicModel:pv,macAddr:00:16:3e:3d:78:10,linkActive:true,network:brbaseboard,filter:vdsm-no-mac-spoofing,specParams:{},deviceId:ab3f9ae9-1d1b-432e-997d-f3458f89cf10,address:{bus:0x01,
slot:0x01, domain:0x, type:pci,
function:0x0},device:bridge,type:interface}
devices={nicModel:pv,macAddr:@MAC_ADDR@,linkActive:true,network:@BRIDGE@,filter:vdsm-no-mac-spoofing,specParams:{},deviceId:@NIC_UUID@,address:{bus:0x01,
slot:0x02, domain:0x, type:pci,
function:0x0},device:bridge,type:interface@BOOT_PXE@}
devices={nicModel:pv,macAddr:00:16:3e:3d:78:30,linkActive:true,network:brstorage,filter:vdsm-no-mac-spoofing,specParams:{},deviceId:ab3f9ae9-1d1b-432e-997d-f3458f89cf30,address:{bus:0x01,
slot:0x03, domain:0x, type:pci,
function:0x0},device:bridge,type:interface}
devices={nicModel:pv,macAddr:00:16:3e:3d:78:40,linkActive:true,network:brcompute,filter:vdsm-no-mac-spoofing,specParams:{},deviceId:ab3f9ae9-1d1b-432e-997d-f3458f89cf40,address:{bus:0x01,
slot:0x04, domain:0x, type:pci,
function:0x0},device:bridge,type:interface}
