Re: [Users] Can I use couple nodes just for storage?
Why not use those nodes as NFS or Gluster storage? -Original Message- From: users-boun...@ovirt.org [mailto:users-boun...@ovirt.org] On Behalf Of Eliezer Croitoru Sent: Tuesday, March 25, 2014 6:58 PM To: users@ovirt.org Subject: [Users] Can I use couple nodes just for storage? I want to use couple nodes for storage. Since these nodes dosn't have VT capability it will be a bit of a problem using ovirt. Can I disable the vt check while installing a single node? Building manually a node? A engine node without VT support? is it possible? As an example I have two server class nodes which works for a very long time and supports sata but lack VT technology. Another option is to use couple tiny devices with ovirt on them to for lower cost home storage. Thanks, Eliezer ___ 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] Instructions to add a remote controlled power strip not in the native list?
- Original Message - > From: "David Smith" > To: "Dan Kenigsberg" > Cc: "Eli Mesika" , "Marek Grac" , > "users" , "Yedidyah Bar > David" > Sent: Tuesday, March 25, 2014 11:36:16 PM > Subject: Re: [Users] Instructions to add a remote controlled power strip not > in the native list? > > Crap, didn't realize I just had to restart vdsm for the new API.py to take > effect. > Anyway I edited fencing.py and added back the compatibility code, and its > all working for now. Good news :-) > > I'm going to work on touch up changes on fence_raritan so that we can get > it submitted into the next release hopefully, all of these other hacks will > become moot at that time. > > > On Tue, Mar 25, 2014 at 2:08 PM, Dan Kenigsberg wrote: > > > On Tue, Mar 25, 2014 at 11:37:13AM -0700, David Smith wrote: > > > I created fence_raritan. > > > > > > Unfortunately it looks like fencing.py is where the legacy --option was > > > translated to --action. I believe ovirt calls fencing.py as a proxy to > > > execute fence_raritan? > > > > > > The version of fence-agents I pulled from git has the backwards > > > compatibility removed; > > > > > https://lists.fedorahosted.org/pipermail/cluster-commits/2013-February/003090.html > > > > > > > > > So if I added support for it in fence_raritan I'm not sure it would work > > (I > > > can try) but also the fence-agents guys probably wouldn't take the > > > submission to have it added to future code. > > > > Indeed - I do not expect upstream fence-agents to accept the legacy > > option. However, you could backport your own code to el6, and create a > > "fence-agents-raritan" rpm from it. > > > > > > > > I edited API.py as in http://gerrit.ovirt.org/#/c/26075/ and re-compiled > > > API.py to pyc and pyo files and copied to all my hosts, yet I'm still > > > getting an error, so I'm wondering if that change is incomplete or I > > missed > > > some other step to make this actually work. It's really a bummer > > > especially since the default behavior with no action is reboot ;) > > > > I suppose that you have missed something. My don't you place API.py > > under /usr/share/vdsm ? And make sure you restart vdsmd, to make the new > > code take effect? > > > > > > > > > > > *Thread-199071::DEBUG::2014-03-25 > > 10:28:10,587::API::1110::vds::(fenceNode) > > > > > fenceNode(addr=10.105.128.25,port=,agent=raritan,user=admin,passwd=,action=status,secure=,options=port=/system1/outlet6)* > > > > > > > > > *Thread-199071::DEBUG::2014-03-25 > > 10:28:13,104::API::1136::vds::(fenceNode) > > > rc 0 in agent=fence_raritan* > > > *ipaddr=10.105.128.25* > > > *login=admin* > > > *option=status* > > > *passwd=* > > > *port=/system1/outlet6 out Success: Rebooted* > > > * err Parse error: Ignoring unknown option 'option=status'* > > > > > > > > > On Tue, Mar 25, 2014 at 6:28 AM, Dan Kenigsberg > > wrote: > > > > > > > On Tue, Mar 25, 2014 at 05:46:58AM -0400, Eli Mesika wrote: > > > > > AFAIK this is related to http://gerrit.ovirt.org/#/c/24343/ which > > > > changed --option to --action > > > > > danken ? > > > > > > > > I smells very much related. > > > > Where is fence_raritan comming from? Could you have the el6 version of > > > > it support the legacy --option name? > > > > > > > > If not, we could consider taking http://gerrit.ovirt.org/#/c/26075/. > > > > > > > > Dan. > > > > > > > ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
[Users] Can I use couple nodes just for storage?
I want to use couple nodes for storage. Since these nodes dosn't have VT capability it will be a bit of a problem using ovirt. Can I disable the vt check while installing a single node? Building manually a node? A engine node without VT support? is it possible? As an example I have two server class nodes which works for a very long time and supports sata but lack VT technology. Another option is to use couple tiny devices with ovirt on them to for lower cost home storage. Thanks, Eliezer ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] Otopi pre-seeded answers and firewall settings
Giuseppe, I should have clarified. I meant to blacklist the packages only for a short time, while you add the nodes to the oVirt environment. Once everything was set up, you would remove these restrictions and yum install iptables. You'd then configure to taste. Glad to hear of your success with the conf file method, though. Thanks, Joshua On Tue, Mar 25, 2014 at 6:15 PM, Giuseppe Ragusa < giuseppe.rag...@hotmail.com> wrote: > 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" > *To: *"Yedidyah Bar David" > *Cc: *"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 > > > ___ 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 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" To: "Yedidyah Bar David" Cc: "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
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. Many thanks again, Giuseppe PS: is there any difference in using "ovirt-hosted-engine-setup" vs. "hosted-engine --deploy" ? From: giuseppe.rag...@hotmail.com To: d...@redhat.com Date: Tue, 25 Mar 2014 22:49:36 +0100 CC: users@ovirt.org 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.). 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" To: "Yedidyah Bar David" Cc: "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 ___ 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" To: "Yedidyah Bar David" Cc: "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] Instructions to add a remote controlled power strip not in the native list?
Crap, didn't realize I just had to restart vdsm for the new API.py to take effect. Anyway I edited fencing.py and added back the compatibility code, and its all working for now. I'm going to work on touch up changes on fence_raritan so that we can get it submitted into the next release hopefully, all of these other hacks will become moot at that time. On Tue, Mar 25, 2014 at 2:08 PM, Dan Kenigsberg wrote: > On Tue, Mar 25, 2014 at 11:37:13AM -0700, David Smith wrote: > > I created fence_raritan. > > > > Unfortunately it looks like fencing.py is where the legacy --option was > > translated to --action. I believe ovirt calls fencing.py as a proxy to > > execute fence_raritan? > > > > The version of fence-agents I pulled from git has the backwards > > compatibility removed; > > > https://lists.fedorahosted.org/pipermail/cluster-commits/2013-February/003090.html > > > > > > So if I added support for it in fence_raritan I'm not sure it would work > (I > > can try) but also the fence-agents guys probably wouldn't take the > > submission to have it added to future code. > > Indeed - I do not expect upstream fence-agents to accept the legacy > option. However, you could backport your own code to el6, and create a > "fence-agents-raritan" rpm from it. > > > > > I edited API.py as in http://gerrit.ovirt.org/#/c/26075/ and re-compiled > > API.py to pyc and pyo files and copied to all my hosts, yet I'm still > > getting an error, so I'm wondering if that change is incomplete or I > missed > > some other step to make this actually work. It's really a bummer > > especially since the default behavior with no action is reboot ;) > > I suppose that you have missed something. My don't you place API.py > under /usr/share/vdsm ? And make sure you restart vdsmd, to make the new > code take effect? > > > > > > > *Thread-199071::DEBUG::2014-03-25 > 10:28:10,587::API::1110::vds::(fenceNode) > > > fenceNode(addr=10.105.128.25,port=,agent=raritan,user=admin,passwd=,action=status,secure=,options=port=/system1/outlet6)* > > > > > > *Thread-199071::DEBUG::2014-03-25 > 10:28:13,104::API::1136::vds::(fenceNode) > > rc 0 in agent=fence_raritan* > > *ipaddr=10.105.128.25* > > *login=admin* > > *option=status* > > *passwd=* > > *port=/system1/outlet6 out Success: Rebooted* > > * err Parse error: Ignoring unknown option 'option=status'* > > > > > > On Tue, Mar 25, 2014 at 6:28 AM, Dan Kenigsberg > wrote: > > > > > On Tue, Mar 25, 2014 at 05:46:58AM -0400, Eli Mesika wrote: > > > > AFAIK this is related to http://gerrit.ovirt.org/#/c/24343/ which > > > changed --option to --action > > > > danken ? > > > > > > I smells very much related. > > > Where is fence_raritan comming from? Could you have the el6 version of > > > it support the legacy --option name? > > > > > > If not, we could consider taking http://gerrit.ovirt.org/#/c/26075/. > > > > > > Dan. > > > > ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] Instructions to add a remote controlled power strip not in the native list?
On Tue, Mar 25, 2014 at 11:37:13AM -0700, David Smith wrote: > I created fence_raritan. > > Unfortunately it looks like fencing.py is where the legacy --option was > translated to --action. I believe ovirt calls fencing.py as a proxy to > execute fence_raritan? > > The version of fence-agents I pulled from git has the backwards > compatibility removed; > https://lists.fedorahosted.org/pipermail/cluster-commits/2013-February/003090.html > > > So if I added support for it in fence_raritan I'm not sure it would work (I > can try) but also the fence-agents guys probably wouldn't take the > submission to have it added to future code. Indeed - I do not expect upstream fence-agents to accept the legacy option. However, you could backport your own code to el6, and create a "fence-agents-raritan" rpm from it. > > I edited API.py as in http://gerrit.ovirt.org/#/c/26075/ and re-compiled > API.py to pyc and pyo files and copied to all my hosts, yet I'm still > getting an error, so I'm wondering if that change is incomplete or I missed > some other step to make this actually work. It's really a bummer > especially since the default behavior with no action is reboot ;) I suppose that you have missed something. My don't you place API.py under /usr/share/vdsm ? And make sure you restart vdsmd, to make the new code take effect? > > > *Thread-199071::DEBUG::2014-03-25 10:28:10,587::API::1110::vds::(fenceNode) > fenceNode(addr=10.105.128.25,port=,agent=raritan,user=admin,passwd=,action=status,secure=,options=port=/system1/outlet6)* > > > *Thread-199071::DEBUG::2014-03-25 10:28:13,104::API::1136::vds::(fenceNode) > rc 0 in agent=fence_raritan* > *ipaddr=10.105.128.25* > *login=admin* > *option=status* > *passwd=* > *port=/system1/outlet6 out Success: Rebooted* > * err Parse error: Ignoring unknown option 'option=status'* > > > On Tue, Mar 25, 2014 at 6:28 AM, Dan Kenigsberg wrote: > > > On Tue, Mar 25, 2014 at 05:46:58AM -0400, Eli Mesika wrote: > > > AFAIK this is related to http://gerrit.ovirt.org/#/c/24343/ which > > changed --option to --action > > > danken ? > > > > I smells very much related. > > Where is fence_raritan comming from? Could you have the el6 version of > > it support the legacy --option name? > > > > If not, we could consider taking http://gerrit.ovirt.org/#/c/26075/. > > > > Dan. > > ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] Instructions to add a remote controlled power strip not in the native list?
I created fence_raritan. Unfortunately it looks like fencing.py is where the legacy --option was translated to --action. I believe ovirt calls fencing.py as a proxy to execute fence_raritan? The version of fence-agents I pulled from git has the backwards compatibility removed; https://lists.fedorahosted.org/pipermail/cluster-commits/2013-February/003090.html So if I added support for it in fence_raritan I'm not sure it would work (I can try) but also the fence-agents guys probably wouldn't take the submission to have it added to future code. I edited API.py as in http://gerrit.ovirt.org/#/c/26075/ and re-compiled API.py to pyc and pyo files and copied to all my hosts, yet I'm still getting an error, so I'm wondering if that change is incomplete or I missed some other step to make this actually work. It's really a bummer especially since the default behavior with no action is reboot ;) *Thread-199071::DEBUG::2014-03-25 10:28:10,587::API::1110::vds::(fenceNode) fenceNode(addr=10.105.128.25,port=,agent=raritan,user=admin,passwd=,action=status,secure=,options=port=/system1/outlet6)* *Thread-199071::DEBUG::2014-03-25 10:28:13,104::API::1136::vds::(fenceNode) rc 0 in agent=fence_raritan* *ipaddr=10.105.128.25* *login=admin* *option=status* *passwd=* *port=/system1/outlet6 out Success: Rebooted* * err Parse error: Ignoring unknown option 'option=status'* On Tue, Mar 25, 2014 at 6:28 AM, Dan Kenigsberg wrote: > On Tue, Mar 25, 2014 at 05:46:58AM -0400, Eli Mesika wrote: > > AFAIK this is related to http://gerrit.ovirt.org/#/c/24343/ which > changed --option to --action > > danken ? > > I smells very much related. > Where is fence_raritan comming from? Could you have the el6 version of > it support the legacy --option name? > > If not, we could consider taking http://gerrit.ovirt.org/#/c/26075/. > > Dan. > ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] Instructions to add a remote controlled power strip not in the native list?
On Tue, Mar 25, 2014 at 05:46:58AM -0400, Eli Mesika wrote: > > > - Original Message - > > From: "David Smith" > > To: "Eli Mesika" > > Cc: "Marek Grac" , "users" , "Yedidyah > > Bar David" > > Sent: Tuesday, March 25, 2014 3:04:53 AM > > Subject: Re: [Users] Instructions to add a remote controlled power strip > > not in the native list? > > > > All right, serious progress. Thanks to all for your nudges in the right > > direction. > > I've managed to get my ovirt to recognize and use the agent. > > I have a new problem however > > > > I get this message when the fence_raritan agent is run: Ignoring unknown > > option 'option=status' fence > > So it appears that my fence_raritan agent is being sent "--option" instead > > of "--action" > > > > Since the default behavior is "reboot" (fence_raritan expects --action= not > > --option=) the systems reboot every time a status request is sent :( hehe > > > > Related:? https://bugzilla.redhat.com/show_bug.cgi?id=987446 > > I'm not using "concurrent" > > Not related > > > > > So the question is, does anyone here know what the best course of action to > > resolve this issue is? My host machines are running centos 6.5. > > Is this problem within a fencing package, ovirt, or other? > > AFAIK this is related to http://gerrit.ovirt.org/#/c/24343/ which changed > --option to --action > danken ? I smells very much related. Where is fence_raritan comming from? Could you have the el6 version of it support the legacy --option name? If not, we could consider taking http://gerrit.ovirt.org/#/c/26075/. Dan. ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] Instructions to add a remote controlled power strip not in the native list?
Yes, they don't have support for raritan. I'm working on getting the fence-agents guys to accept my new code, however, I'm also testing it by getting it working into oVirt 3.3 (since that's what I've got installed and working) Thanks! On Tue, Mar 25, 2014 at 10:28 AM, Dan Kenigsberg wrote: > On Tue, Mar 25, 2014 at 09:00:42AM -0700, David Smith wrote: > > oh I see, since I have the latest fence, that's where option is now > > missing, got it.. just a minor tweak to api.py ;) > > > > > > On Tue, Mar 25, 2014 at 8:25 AM, David Smith > wrote: > > > > > Hehe. Apparently not, unless I pulled an old copy of fence-agents > somehow > > > direct from git? I used the master branch too. > > > > > > > > Is there any reason for you not to use the pre-packaged fence-agents? > I am not very happy about intoducing non-necessary changes to > old stable branches like ovirt-3.3. To do this, I'd need a BZ opened, > explaining why this is actually a good thing. > > Regards, > Dan. > ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] Instructions to add a remote controlled power strip not in the native list?
On Tue, Mar 25, 2014 at 09:00:42AM -0700, David Smith wrote: > oh I see, since I have the latest fence, that's where option is now > missing, got it.. just a minor tweak to api.py ;) > > > On Tue, Mar 25, 2014 at 8:25 AM, David Smith wrote: > > > Hehe. Apparently not, unless I pulled an old copy of fence-agents somehow > > direct from git? I used the master branch too. > > > > Is there any reason for you not to use the pre-packaged fence-agents? I am not very happy about intoducing non-necessary changes to old stable branches like ovirt-3.3. To do this, I'd need a BZ opened, explaining why this is actually a good thing. Regards, Dan. ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] hosted engine help
On 03/25/2014 06:34 PM, Jiri Moskovcak wrote:
On 03/13/2014 05:25 PM, Jason Brooks wrote:
- Original Message -
From: "Greg Padgett"
To: "Jason Brooks"
Cc: "Sandro Bonazzola" , users@ovirt.org,
"Martin Sivak"
Sent: Tuesday, March 11, 2014 7:52:42 AM
Subject: Re: [Users] hosted engine help
On 03/11/2014 04:09 PM, Sandro Bonazzola wrote:
Il 07/03/2014 01:10, Jason Brooks ha scritto:
Hey everyone, I've been testing out oVirt 3.4 w/ hosted engine, and
while I've managed to bring the engine up, I've only been able to
do it
manually, using "hosted-engine --vm-start".
The ovirt-ha-agent service fails reliably for me, erroring out with
"RequestError: Request failed: success."
I've pasted error passages from the ha agent and vdsm logs below.
Any pointers?
Regards, Jason
***
ovirt-ha-agent.log
MainThread::CRITICAL::2014-03-06
18:48:30,622::agent::103::ovirt_hosted_engine_ha.agent.agent.Agent::(run)
Could not start ha-agent
Traceback (most recent call last):
File
"/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agent/agent.py",
line 97, in run
self._run_agent()
File
"/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agent/agent.py",
line 154, in _run_agent
hosted_engine.HostedEngine(self.shutdown_requested).start_monitoring()
File
"/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agent/hosted_engine.py",
line 303, in start_monitoring
for old_state, state, delay in self.fsm:
File
"/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/lib/fsm/machine.py",
line 125, in next
new_data = self.refresh(self._state.data)
File
"/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agent/state_machine.py",
line 77, in refresh
stats.update(self.hosted_engine.collect_stats())
File
"/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agent/hosted_engine.py",
line 623, in collect_stats
constants.SERVICE_TYPE)
File
"/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/lib/brokerlink.py",
line 171, in get_stats_from_storage
result = self._checked_communicate(request)
File
"/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/lib/brokerlink.py",
line 198, in _checked_communicate
raise RequestError("Request failed: {0}".format(msg))
RequestError: Request failed: success
vdsm.log
Thread-29::ERROR::2014-03-06
18:48:11,101::API::1607::vds::(_getHaInfo)
failed to retrieve Hosted Engine HA info
Traceback (most recent call last):
File "/usr/share/vdsm/API.py", line 1598, in _getHaInfo
stats = instance.get_all_stats()
File
"/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/client/client.py",
line 86, in get_all_stats
constants.SERVICE_TYPE)
File
"/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/lib/brokerlink.py",
line 171, in get_stats_from_storage
result = self._checked_communicate(request)
File
"/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/lib/brokerlink.py",
line 198, in _checked_communicate
raise RequestError("Request failed: {0}".format(msg))
RequestError: Request failed: success
Greg, Martin, "Request failed: success" ?
Hi Jason,
I talked to Martin about this and opened a bug [1]/submitted a patch
[2].
Based on your mail, I'm not sure if you experienced a race
condition or
some other issue. This patch should help the former case, but if you're
still experiencing problems then we would need to investigate further.
I made these changes to my install and now I get a different error:
MainThread::CRITICAL::2014-03-13
12:05:47,749::agent::103::ovirt_hosted_engine_ha.agent.agent.Agent::(run)
Could not start ha-agent
Traceback (most recent call last):
File
"/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agent/agent.py",
line 97, in run
self._run_agent()
File
"/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agent/agent.py",
line 154, in _run_agent
hosted_engine.HostedEngine(self.shutdown_requested).start_monitoring()
File
"/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agent/hosted_engine.py",
line 303, in start_monitoring
for old_state, state, delay in self.fsm:
File
"/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/lib/fsm/machine.py",
line 125, in next
new_data = self.refresh(self._state.data)
File
"/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agent/state_machine.py",
line 77, in refresh
stats.update(self.hosted_engine.collect_stats())
File
"/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agent/hosted_engine.py",
line 623, in collect_stats
constants.SERVICE_TYPE)
File
"/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/lib/brokerlink.py",
line 171, in get_stats_from_storage
result = self._checked_communicate(request)
File
"/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/lib/brokerlink.py",
line 191, in _checked_communicate
return parts[1]
IndexError: list index out of range
I'm attaching my vds
Re: [Users] hosted engine help
- Original Message -
> From: "Jiri Moskovcak"
> To: "Jason Brooks" , "Greg Padgett"
> Cc: users@ovirt.org
> Sent: Tuesday, March 25, 2014 10:34:16 AM
> Subject: Re: [Users] hosted engine help
>
> On 03/13/2014 05:25 PM, Jason Brooks wrote:
> >
> >
> > - Original Message -
> >> From: "Greg Padgett"
> >> To: "Jason Brooks"
> >> Cc: "Sandro Bonazzola" , users@ovirt.org, "Martin
> >> Sivak"
> >> Sent: Tuesday, March 11, 2014 7:52:42 AM
> >> Subject: Re: [Users] hosted engine help
> >>
> >> On 03/11/2014 04:09 PM, Sandro Bonazzola wrote:
> >>> Il 07/03/2014 01:10, Jason Brooks ha scritto:
> Hey everyone, I've been testing out oVirt 3.4 w/ hosted engine, and
> while I've managed to bring the engine up, I've only been able to do it
> manually, using "hosted-engine --vm-start".
>
> The ovirt-ha-agent service fails reliably for me, erroring out with
> "RequestError: Request failed: success."
>
> I've pasted error passages from the ha agent and vdsm logs below.
>
> Any pointers?
>
> Regards, Jason
>
> ***
>
> ovirt-ha-agent.log
>
> MainThread::CRITICAL::2014-03-06
> 18:48:30,622::agent::103::ovirt_hosted_engine_ha.agent.agent.Agent::(run)
> Could not start ha-agent
> Traceback (most recent call last):
> File
> "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agent/agent.py",
> line 97, in run
> self._run_agent()
> File
> "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agent/agent.py",
> line 154, in _run_agent
>
> hosted_engine.HostedEngine(self.shutdown_requested).start_monitoring()
> File
> "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agent/hosted_engine.py",
> line 303, in start_monitoring
> for old_state, state, delay in self.fsm:
> File
> "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/lib/fsm/machine.py",
> line 125, in next
> new_data = self.refresh(self._state.data)
> File
> "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agent/state_machine.py",
> line 77, in refresh
> stats.update(self.hosted_engine.collect_stats())
> File
> "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agent/hosted_engine.py",
> line 623, in collect_stats
> constants.SERVICE_TYPE)
> File
> "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/lib/brokerlink.py",
> line 171, in get_stats_from_storage
> result = self._checked_communicate(request)
> File
> "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/lib/brokerlink.py",
> line 198, in _checked_communicate
> raise RequestError("Request failed: {0}".format(msg))
> RequestError: Request failed: success
>
>
> vdsm.log
>
> Thread-29::ERROR::2014-03-06 18:48:11,101::API::1607::vds::(_getHaInfo)
> failed to retrieve Hosted Engine HA info
> Traceback (most recent call last):
> File "/usr/share/vdsm/API.py", line 1598, in _getHaInfo
> stats = instance.get_all_stats()
> File
> "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/client/client.py",
> line 86, in get_all_stats
> constants.SERVICE_TYPE)
> File
> "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/lib/brokerlink.py",
> line 171, in get_stats_from_storage
> result = self._checked_communicate(request)
> File
> "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/lib/brokerlink.py",
> line 198, in _checked_communicate
> raise RequestError("Request failed: {0}".format(msg))
> RequestError: Request failed: success
> >>>
> >>>
> >>> Greg, Martin, "Request failed: success" ?
> >>
> >> Hi Jason,
> >>
> >> I talked to Martin about this and opened a bug [1]/submitted a patch [2].
> >>Based on your mail, I'm not sure if you experienced a race condition or
> >> some other issue. This patch should help the former case, but if you're
> >> still experiencing problems then we would need to investigate further.
> >
> > I made these changes to my install and now I get a different error:
> >
> > MainThread::CRITICAL::2014-03-13
> > 12:05:47,749::agent::103::ovirt_hosted_engine_ha.agent.agent.Agent::(run)
> > Could not start ha-agent
> > Traceback (most recent call last):
> >File
> >"/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agent/agent.py",
> >line 97, in run
> > self._run_agent()
> >File
> >"/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agent/agent.py",
> >line 154, in _run_agent
> > hosted_engine.HostedEngine(self.shutdown_requested).start_monitoring()
> >File
> >
> > "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agent/hosted_engine.py",
> >line 303, in start_monitoring
> >
Re: [Users] hosted engine help
On 03/13/2014 05:25 PM, Jason Brooks wrote:
- Original Message -
From: "Greg Padgett"
To: "Jason Brooks"
Cc: "Sandro Bonazzola" , users@ovirt.org, "Martin Sivak"
Sent: Tuesday, March 11, 2014 7:52:42 AM
Subject: Re: [Users] hosted engine help
On 03/11/2014 04:09 PM, Sandro Bonazzola wrote:
Il 07/03/2014 01:10, Jason Brooks ha scritto:
Hey everyone, I've been testing out oVirt 3.4 w/ hosted engine, and
while I've managed to bring the engine up, I've only been able to do it
manually, using "hosted-engine --vm-start".
The ovirt-ha-agent service fails reliably for me, erroring out with
"RequestError: Request failed: success."
I've pasted error passages from the ha agent and vdsm logs below.
Any pointers?
Regards, Jason
***
ovirt-ha-agent.log
MainThread::CRITICAL::2014-03-06
18:48:30,622::agent::103::ovirt_hosted_engine_ha.agent.agent.Agent::(run)
Could not start ha-agent
Traceback (most recent call last):
File
"/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agent/agent.py",
line 97, in run
self._run_agent()
File
"/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agent/agent.py",
line 154, in _run_agent
hosted_engine.HostedEngine(self.shutdown_requested).start_monitoring()
File
"/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agent/hosted_engine.py",
line 303, in start_monitoring
for old_state, state, delay in self.fsm:
File
"/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/lib/fsm/machine.py",
line 125, in next
new_data = self.refresh(self._state.data)
File
"/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agent/state_machine.py",
line 77, in refresh
stats.update(self.hosted_engine.collect_stats())
File
"/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agent/hosted_engine.py",
line 623, in collect_stats
constants.SERVICE_TYPE)
File
"/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/lib/brokerlink.py",
line 171, in get_stats_from_storage
result = self._checked_communicate(request)
File
"/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/lib/brokerlink.py",
line 198, in _checked_communicate
raise RequestError("Request failed: {0}".format(msg))
RequestError: Request failed: success
vdsm.log
Thread-29::ERROR::2014-03-06 18:48:11,101::API::1607::vds::(_getHaInfo)
failed to retrieve Hosted Engine HA info
Traceback (most recent call last):
File "/usr/share/vdsm/API.py", line 1598, in _getHaInfo
stats = instance.get_all_stats()
File
"/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/client/client.py",
line 86, in get_all_stats
constants.SERVICE_TYPE)
File
"/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/lib/brokerlink.py",
line 171, in get_stats_from_storage
result = self._checked_communicate(request)
File
"/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/lib/brokerlink.py",
line 198, in _checked_communicate
raise RequestError("Request failed: {0}".format(msg))
RequestError: Request failed: success
Greg, Martin, "Request failed: success" ?
Hi Jason,
I talked to Martin about this and opened a bug [1]/submitted a patch [2].
Based on your mail, I'm not sure if you experienced a race condition or
some other issue. This patch should help the former case, but if you're
still experiencing problems then we would need to investigate further.
I made these changes to my install and now I get a different error:
MainThread::CRITICAL::2014-03-13
12:05:47,749::agent::103::ovirt_hosted_engine_ha.agent.agent.Agent::(run) Could
not start ha-agent
Traceback (most recent call last):
File
"/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agent/agent.py", line
97, in run
self._run_agent()
File
"/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agent/agent.py", line
154, in _run_agent
hosted_engine.HostedEngine(self.shutdown_requested).start_monitoring()
File
"/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agent/hosted_engine.py",
line 303, in start_monitoring
for old_state, state, delay in self.fsm:
File
"/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/lib/fsm/machine.py",
line 125, in next
new_data = self.refresh(self._state.data)
File
"/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agent/state_machine.py",
line 77, in refresh
stats.update(self.hosted_engine.collect_stats())
File
"/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agent/hosted_engine.py",
line 623, in collect_stats
constants.SERVICE_TYPE)
File
"/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/lib/brokerlink.py",
line 171, in get_stats_from_storage
result = self._checked_communicate(request)
File
"/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/lib/brokerlink.py",
line 191, in _checked_communicate
return parts[1]
IndexError: list index out of range
I'm attaching my vdsm.log, agent.log and broker.log.
Ja
Re: [Users] Instructions to add a remote controlled power strip not in the native list?
Eli, I changed the line in API.py and ran py_compile to obtain API.pyc and pyo files, copied them to all hypervisors, and I'm still getting option=status.. Did I miss something else? Thread-199071::DEBUG::2014-03-25 10:28:10,587::API::1110::vds::(fenceNode) fenceNode(addr=10.105.128.25,port=,agent=raritan,user=admin,passwd=,action=s tatus,secure=,options=port=/system1/outlet6) Thread-199071::DEBUG::2014-03-25 10:28:13,104::API::1136::vds::(fenceNode) rc 0 in agent=fence_raritan ipaddr=10.105.128.25 login=admin option=status passwd= port=/system1/outlet6 out Success: Rebooted err Parse error: Ignoring unknown option 'option=status' Looks like in the first command the option was indeed changed to "action=status" but the return status showed "option=status" was used? On Tue, Mar 25, 2014 at 2:46 AM, Eli Mesika wrote: > > > - Original Message - > > From: "David Smith" > > To: "Eli Mesika" > > Cc: "Marek Grac" , "users" , > "Yedidyah Bar David" > > Sent: Tuesday, March 25, 2014 3:04:53 AM > > Subject: Re: [Users] Instructions to add a remote controlled power strip > not in the native list? > > > > All right, serious progress. Thanks to all for your nudges in the right > > direction. > > I've managed to get my ovirt to recognize and use the agent. > > I have a new problem however > > > > I get this message when the fence_raritan agent is run: Ignoring unknown > > option 'option=status' fence > > So it appears that my fence_raritan agent is being sent "--option" > instead > > of "--action" > > > > Since the default behavior is "reboot" (fence_raritan expects --action= > not > > --option=) the systems reboot every time a status request is sent :( hehe > > > > Related:? https://bugzilla.redhat.com/show_bug.cgi?id=987446 > > I'm not using "concurrent" > > Not related > > > > > So the question is, does anyone here know what the best course of action > to > > resolve this issue is? My host machines are running centos 6.5. > > Is this problem within a fencing package, ovirt, or other? > > AFAIK this is related to http://gerrit.ovirt.org/#/c/24343/ which changed > --option to --action > danken ? > > > > > I tried to set option=action in the engine database, but it appears > theres > > probably only a few (3?) mappings possible there, unless I'm wrong and > > there are more? > > > > > > This is what I've changed for now, using 3.3 cluster; > > UPDATE "vdc_options" SET > > > option_value='apc:secure=secure,port=ipport,slot=port;apc_snmp:port=port;bladecenter:secure=secure,port=ipport,slot=port;cisco_ucs:secure=ssl,slot=port;drac5:secure=secure,slot=port;eps:slot=port;ilo:secure=ssl,port=ipport;ipmilan:;ilo2:secure=ssl,port=ipport;ilo3:;ilo4:;rsa:secure=secure,port=ipport;rsb:;wti:secure=secure,port=ipport,slot=port;raritan:slot=port,port=ipport;' > > where option_id=389; > > > > UPDATE "vdc_options" SET > > > option_value='apc,apc_snmp,bladecenter,cisco_ucs,drac5,eps,ilo,ilo2,ilo3,ilo4,ipmilan,rsa,rsb,wti,raritan' > > where option_id=395; > > > > > > On Mon, Mar 24, 2014 at 2:07 PM, Eli Mesika wrote: > > > > > > > > > > > - Original Message - > > > > From: "David Smith" > > > > To: "Eli Mesika" > > > > Cc: "Marek Grac" , "users" , > > > "Yedidyah Bar David" > > > > Sent: Friday, March 21, 2014 4:33:17 PM > > > > Subject: Re: [Users] Instructions to add a remote controlled power > strip > > > not in the native list? > > > > > > > > Hey guys, > > > > > > > > I submitted an initial agent for raritan to the fence-agents group, > > > however > > > > I have a feeling after experimenting with the ipmilan agent that my > agent > > > > won't work with oVirt; > > > > > > Can you please elaborate on that ? what will not work and why this is > > > related to the ipmilan card ? > > > > > > > > > > > Is the command set for each agent determined by the oVirt database > > > itself, > > > > in other words, when I add the agent the abilities are then added? > > > > > > Please see http://www.ovirt.org/Custom_Fencing for the exact set of > > > fields in database involved in that. > > > If you are implementing raritan PM agent , you should have > fence_raritan > > > in /usr/sbin of the host that is selected as a proxy for the fencing > > > operation, you should also make sure that this script has similar > > > permissions as other scripts bundled with the fence-agents RPM > > > > > > > > > > > For example the agent I submitted only has support for connectivity > > > > settings and power on/off/reboot as well as some delays. Also > currently > > > it > > > > requires that the port be specified as a path ie /system1/outlet1 > > > > > > > > Will this work as an outlet path? > > > > > > You can try to put that in the options field in the UI for the PM agent > > > definition , i.e "port=/system1/outlet1" > > > > > > > Minimum commands required to work? > > > > > > Not sure I go you here , please elaborate/explain > > > > > > > > > > > Thanks > > > > > > > > > > ___
Re: [Users] Instructions to add a remote controlled power strip not in the native list?
oh I see, since I have the latest fence, that's where option is now missing, got it.. just a minor tweak to api.py ;) On Tue, Mar 25, 2014 at 8:25 AM, David Smith wrote: > Hehe. Apparently not, unless I pulled an old copy of fence-agents somehow > direct from git? I used the master branch too. > > ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] Instructions to add a remote controlled power strip not in the native list?
Hehe. Apparently not, unless I pulled an old copy of fence-agents somehow direct from git? I used the master branch too. On Tue, Mar 25, 2014 at 2:46 AM, Eli Mesika wrote: > > > - Original Message - > > From: "David Smith" > > To: "Eli Mesika" > > Cc: "Marek Grac" , "users" , > "Yedidyah Bar David" > > Sent: Tuesday, March 25, 2014 3:04:53 AM > > Subject: Re: [Users] Instructions to add a remote controlled power strip > not in the native list? > > > > All right, serious progress. Thanks to all for your nudges in the right > > direction. > > I've managed to get my ovirt to recognize and use the agent. > > I have a new problem however > > > > I get this message when the fence_raritan agent is run: Ignoring unknown > > option 'option=status' fence > > So it appears that my fence_raritan agent is being sent "--option" > instead > > of "--action" > > > > Since the default behavior is "reboot" (fence_raritan expects --action= > not > > --option=) the systems reboot every time a status request is sent :( hehe > > > > Related:? https://bugzilla.redhat.com/show_bug.cgi?id=987446 > > I'm not using "concurrent" > > Not related > > > > > So the question is, does anyone here know what the best course of action > to > > resolve this issue is? My host machines are running centos 6.5. > > Is this problem within a fencing package, ovirt, or other? > > AFAIK this is related to http://gerrit.ovirt.org/#/c/24343/ which changed > --option to --action > danken ? > > > > > I tried to set option=action in the engine database, but it appears > theres > > probably only a few (3?) mappings possible there, unless I'm wrong and > > there are more? > > > > > > This is what I've changed for now, using 3.3 cluster; > > UPDATE "vdc_options" SET > > > option_value='apc:secure=secure,port=ipport,slot=port;apc_snmp:port=port;bladecenter:secure=secure,port=ipport,slot=port;cisco_ucs:secure=ssl,slot=port;drac5:secure=secure,slot=port;eps:slot=port;ilo:secure=ssl,port=ipport;ipmilan:;ilo2:secure=ssl,port=ipport;ilo3:;ilo4:;rsa:secure=secure,port=ipport;rsb:;wti:secure=secure,port=ipport,slot=port;raritan:slot=port,port=ipport;' > > where option_id=389; > > > > UPDATE "vdc_options" SET > > > option_value='apc,apc_snmp,bladecenter,cisco_ucs,drac5,eps,ilo,ilo2,ilo3,ilo4,ipmilan,rsa,rsb,wti,raritan' > > where option_id=395; > > > > > > On Mon, Mar 24, 2014 at 2:07 PM, Eli Mesika wrote: > > > > > > > > > > > - Original Message - > > > > From: "David Smith" > > > > To: "Eli Mesika" > > > > Cc: "Marek Grac" , "users" , > > > "Yedidyah Bar David" > > > > Sent: Friday, March 21, 2014 4:33:17 PM > > > > Subject: Re: [Users] Instructions to add a remote controlled power > strip > > > not in the native list? > > > > > > > > Hey guys, > > > > > > > > I submitted an initial agent for raritan to the fence-agents group, > > > however > > > > I have a feeling after experimenting with the ipmilan agent that my > agent > > > > won't work with oVirt; > > > > > > Can you please elaborate on that ? what will not work and why this is > > > related to the ipmilan card ? > > > > > > > > > > > Is the command set for each agent determined by the oVirt database > > > itself, > > > > in other words, when I add the agent the abilities are then added? > > > > > > Please see http://www.ovirt.org/Custom_Fencing for the exact set of > > > fields in database involved in that. > > > If you are implementing raritan PM agent , you should have > fence_raritan > > > in /usr/sbin of the host that is selected as a proxy for the fencing > > > operation, you should also make sure that this script has similar > > > permissions as other scripts bundled with the fence-agents RPM > > > > > > > > > > > For example the agent I submitted only has support for connectivity > > > > settings and power on/off/reboot as well as some delays. Also > currently > > > it > > > > requires that the port be specified as a path ie /system1/outlet1 > > > > > > > > Will this work as an outlet path? > > > > > > You can try to put that in the options field in the UI for the PM agent > > > definition , i.e "port=/system1/outlet1" > > > > > > > Minimum commands required to work? > > > > > > Not sure I go you here , please elaborate/explain > > > > > > > > > > > Thanks > > > > > > > > > > ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] run once via ovirt-shell 3.3?
On 03/24/2014 05:40 PM, Sven Kieske wrote:
> thanks for pointing me in the right direction!
>
> Bonusquestion: Is it possible to use shell variables
> or to pipe them somehow for script usage?
>
> What I found in the wiki seems not to work ( ${VAR} )?
>
It isn't possible to use shell variables from within ovirt-shell
propmpt, but you can pass a command to it:
# VAR=myvm
# ovirt-shell --execute-command "show vm ${VAR}"
Or you can use here documents:
# VAR=myvm
# ovirt-shell <<.
show vm ${VAR}
.
--
Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
3ºD, 28016 Madrid, Spain
Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] Acceptance test
Hi, there are some test scenarios on the wiki, but I think they don't meet your requirements, as they are mostly functional test for devs. I really can't read this proprietary docx document, would you mind converting it into something readable like a pdf? here it is :-) cheers, dron Thanks Am 25.03.2014 12:57, schrieb Koen Vanoppen: Dear all, No I'm not spamming :-). I just have a question not regarding errors or bugs :-). We are using oVirt for some time now in Brussels Airport. Now after the implementation we have to put oVirt to the test... Does anybody knows if there are some existing test documents for testing a ovirt environment on up time and toughness? I have added a example from a VMWare environment from the windows system engineers. Hope someone can provide me with some documents :-). Kind regards, Scenario.pdf Description: Adobe PDF document <> smime.p7s Description: Elektronicky podpis S/MIME ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] Force certain VMs to be on different hosts
- Original Message - > From: "Ted Miller" > To: users@ovirt.org > Sent: Monday, March 24, 2014 8:27:31 PM > Subject: Re: [Users] Force certain VMs to be on different hosts > > Scott > > On 3/19/2014 10:30 AM, Scott Ocken wrote: > > Ted, > > > > Yes! This is exactly what I was looking for. I think you described it > > better than I did. This feature would be really nice. > > > > Thanks > > Scott > > > > Quoting Ted Miller : > > > >> I think what the OP is asking for a designation as a "redundant group 1". > >> He may have 10 hosts and 3 VMs in "redundant group 1". He doesn't care > >> which hosts they run on, as long as they are three separate hosts. > >> > >> I can see this as being fairly widely applicable. If you have multiple > >> web servers for load sharing, you don't want them all running on the same > >> host, because VM load is going to peak on them at the same times. oVirt > >> has no way of knowing that unless you give oVirt a hint to spread things > >> around. The web group might also want to split up the server that spreads > >> the jobs around, and a database server used by all the web hosts. I can > >> see easily ending up with a group of 5 machines (3 web servers, a load > >> sharing controller, and a database server) that you want spread across any > >> 5 of the 15 servers in a cluster, because their loads are all going to > >> spike together. You don't want oVirt having to try to migrate some of them > >> during a load spike, because oVirt noticed that a host with 3 of the 5 is > >> overloaded. > >> > >> Not my situation, but one I can see the usefulness of. > >> Ted Miller > >> Elkhart, IN, USA > >> > >> On 3/18/2014 11:54 AM, Meital Bourvine wrote: > >>> Hi Scott, > >>> > >>> Click on a vm > >>> Edit > >>> Show Advanced Options > >>> Host > >>> "Start Running on" > >>> > >>> - Original Message - > From: "Scott Ocken" > To: Users@ovirt.org > Sent: Tuesday, March 18, 2014 5:08:24 PM > Subject: [Users] Force certain VMs to be on different hosts > > Is there a way to have certain VMs to be on different hosts? (assuming > there are enough hosts) > > IE. I have a db cluster of 3 VMs. I would like each one to always be > on different hosts. That way if a host goes down my db cluster is > still happy while migration happens. Or if migration fails I am still > good. > > Thanks > Scott > >> > >> Ted Miller > It looks like the Negative Affinity/Anti-Affinity feature that Itamar Hein > pointed out in his email, with a feature page at > http://www.ovirt.org/Features/VM-Affinity includes what you are trying to > do. +1 :-) > This is in 3.4, which in the QA process now. As far as I know this feature is fully tested and verified for version 3.4. I'd love for feedback! and would like to assist in anything :) > > Ted Miller > Elkhart, IN, USA > > ___ > 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] oVirt 3.5 planning
Maybe I'm missing something but currently when I register a node it gets assigned to the DEFAULT datacenter. As we like to have a separate DC for specific customers, I would like to register the node to a chosen DC through a PXE kernel parameter or the Node admin interface. Kind regards, Jorick Astrego Netbulae ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] Acceptance test
Hi, there are some test scenarios on the wiki, but I think they don't meet your requirements, as they are mostly functional test for devs. I really can't read this proprietary docx document, would you mind converting it into something readable like a pdf? Thanks Am 25.03.2014 12:57, schrieb Koen Vanoppen: > Dear all, > > No I'm not spamming :-). I just have a question not regarding errors or > bugs :-). > We are using oVirt for some time now in Brussels Airport. Now after the > implementation we have to put oVirt to the test... > > Does anybody knows if there are some existing test documents for testing a > ovirt environment on up time and toughness? I have added a example from a > VMWare environment from the windows system engineers. > > Hope someone can provide me with some documents :-). > > Kind regards, -- 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] Vds broker
I thought that this looked familiar :-). Oh damn... I really need to get to sleep... SORRY guys 2014-03-25 12:53 GMT+01:00 Omer Frenkel : > > > -- > > *From: *"Koen Vanoppen" > *To: *users@ovirt.org > *Sent: *Tuesday, March 25, 2014 1:41:16 PM > *Subject: *[Users] Vds broker > > > Hi Guys, > > I already send a issue with the vds for a specific host, > but now my engine.log is spitting even more errors... > > Any Ideas whats happening? > > looks like you are facing this bug, that you opened, and already solved in > 3.3.2 :) > https://bugzilla.redhat.com/show_bug.cgi?id=1035297 > > > ___ > 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
[Users] Acceptance test
Dear all, No I'm not spamming :-). I just have a question not regarding errors or bugs :-). We are using oVirt for some time now in Brussels Airport. Now after the implementation we have to put oVirt to the test... Does anybody knows if there are some existing test documents for testing a ovirt environment on up time and toughness? I have added a example from a VMWare environment from the windows system engineers. Hope someone can provide me with some documents :-). Kind regards, Koen Scenario.docx Description: application/vnd.openxmlformats-officedocument.wordprocessingml.document ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] Vds broker
- Original Message - > From: "Koen Vanoppen" > To: users@ovirt.org > Sent: Tuesday, March 25, 2014 1:41:16 PM > Subject: [Users] Vds broker > Hi Guys, > I already send a issue with the vds for a specific host, > but now my engine.log is spitting even more errors... > Any Ideas whats happening? looks like you are facing this bug, that you opened, and already solved in 3.3.2 :) https://bugzilla.redhat.com/show_bug.cgi?id=1035297 > ___ > 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] Vds broker
And this happens when I try to migrate a vm to a newly added host: 014-03-25 12:49:24,223 INFO [org.ovirt.engine.core.bll.StopVmCommand] (pool-6-thread-47) [3fbc17c4] Running command: StopVmCommand internal: false. Entities affected : ID: c8d88175-46ae-43fc-a335-1f3badc91f2d Type: VM 2014-03-25 12:49:24,328 INFO [org.ovirt.engine.core.vdsbroker.DestroyVmVDSCommand] (pool-6-thread-47) [3fbc17c4] START, DestroyVmVDSCommand(HostName = mercury1, HostId = b34902ea-ad11-45d3-96ee-47de1864e4e0, vmId=c8d88175-46ae-43fc-a335-1f3badc91f2d, force=false, secondsToWait=0, gracefully=false), log id: 6ced0d30 2014-03-25 12:49:24,352 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.DestroyVDSCommand] (pool-6-thread-47) [3fbc17c4] START, DestroyVDSCommand(HostName = mercury1, HostId = b34902ea-ad11-45d3-96ee-47de1864e4e0, vmId=c8d88175-46ae-43fc-a335-1f3badc91f2d, force=false, secondsToWait=0, gracefully=false), log id: 2750e4d 2014-03-25 12:49:25,028 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.DestroyVDSCommand] (pool-6-thread-47) [3fbc17c4] FINISH, DestroyVDSCommand, log id: 2750e4d 2014-03-25 12:49:25,069 INFO [org.ovirt.engine.core.vdsbroker.DestroyVmVDSCommand] (pool-6-thread-47) [3fbc17c4] FINISH, DestroyVmVDSCommand, return: Down, log id: 6ced0d30 2014-03-25 12:49:25,105 INFO [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (pool-6-thread-47) [3fbc17c4] Correlation ID: 3fbc17c4, Job ID: fe838ca6-a821-479a-84f4-4003d1d4aa79, Call Stack: null, Custom Event ID: -1, Message: VM test powered off by admin@internal (Host: mercury1). 2014-03-25 12:49:26,928 WARN [org.ovirt.engine.core.vdsbroker.VdsManager] (DefaultQuartzScheduler_Worker-35) Failed to refresh VDS , vds = 497c0af3-4897-46f4-bffa-049bcd0ae713 : buran, error = java.lang.NullPointerException, continuing.: java.lang.NullPointerException 2014-03-25 12:49:32,874 INFO [org.ovirt.engine.core.bll.RemoveVmCommand] (ajp--127.0.0.1-8702-7) [193ff58e] Lock Acquired to object EngineLock [exclusiveLocks= key: c8d88175-46ae-43fc-a335-1f3badc91f2d value: VM , sharedLocks= ] 2014-03-25 12:49:32,922 INFO [org.ovirt.engine.core.bll.RemoveVmCommand] (pool-6-thread-47) [193ff58e] Running command: RemoveVmCommand internal: false. Entities affected : ID: c8d88175-46ae-43fc-a335-1f3badc91f2d Type: VM 2014-03-25 12:49:32,923 INFO [org.ovirt.engine.core.vdsbroker.SetVmStatusVDSCommand] (pool-6-thread-47) [193ff58e] START, SetVmStatusVDSCommand( vmId = c8d88175-46ae-43fc-a335-1f3badc91f2d, status = ImageLocked), log id: 5fd52b9 2014-03-25 12:49:32,929 INFO [org.ovirt.engine.core.vdsbroker.SetVmStatusVDSCommand] (pool-6-thread-47) [193ff58e] FINISH, SetVmStatusVDSCommand, log id: 5fd52b9 2014-03-25 12:49:32,937 INFO [org.ovirt.engine.core.bll.RemoveVmCommand] (pool-6-thread-47) [193ff58e] Lock freed to object EngineLock [exclusiveLocks= key: c8d88175-46ae-43fc-a335-1f3badc91f2d value: VM , sharedLocks= ] 2014-03-25 12:49:33,034 INFO [org.ovirt.engine.core.bll.RemoveAllVmImagesCommand] (pool-6-thread-47) Running command: RemoveAllVmImagesCommand internal: true. Entities affected : ID: c8d88175-46ae-43fc-a335-1f3badc91f2d Type: VM 2014-03-25 12:49:33,072 INFO [org.ovirt.engine.core.bll.RemoveImageCommand] (pool-6-thread-47) Running command: RemoveImageCommand internal: true. Entities affected : ID: ---- Type: Storage 2014-03-25 12:49:33,117 INFO [org.ovirt.engine.core.vdsbroker.irsbroker.DeleteImageGroupVDSCommand] (pool-6-thread-47) START, DeleteImageGroupVDSCommand( storagePoolId = 1d03dc05-008b-4d14-97ce-b17bd714183d, ignoreFailoverLimit = false, storageDomainId = 2d289011-8671-4995-8015-d5bdf6a7e9dc, imageGroupId = 69c393a2-4d5a-405e-9e77-677c3b636ec3, postZeros = false, forceDelete = false), log id: 5a78ac25 2014-03-25 12:49:33,482 INFO [org.ovirt.engine.core.vdsbroker.irsbroker.DeleteImageGroupVDSCommand] (pool-6-thread-47) FINISH, DeleteImageGroupVDSCommand, log id: 5a78ac25 2014-03-25 12:49:33,527 INFO [org.ovirt.engine.core.bll.CommandAsyncTask] (pool-6-thread-47) CommandAsyncTask::Adding CommandMultiAsyncTasks object for command 755d17e4-701b-434f-9c25-9cded5d84db0 2014-03-25 12:49:33,535 INFO [org.ovirt.engine.core.bll.CommandMultiAsyncTasks] (pool-6-thread-47) CommandMultiAsyncTasks::AttachTask: Attaching task c12bd7c5-fea7-48c5-822e-61f38a417dbd to command 755d17e4-701b-434f-9c25-9cded5d84db0. 2014-03-25 12:49:33,556 INFO [org.ovirt.engine.core.bll.AsyncTaskManager] (pool-6-thread-47) Adding task c12bd7c5-fea7-48c5-822e-61f38a417dbd (Parent Command RemoveVm, Parameters Type org.ovirt.engine.core.common.asynctasks.AsyncTaskParameters), polling hasn't started yet.. 2014-03-25 12:49:33,766 INFO [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (pool-6-thread-47) Correlation ID: 193ff58e, Job ID: 990e8f42-b6af-403b-ab95-8dda0afb10cd, Call Stack: null, Custom Event ID: -1, Message: VM test was successfully removed. 2014-03-25 12:49:33,770 INFO [org.ovirt.engine.core.bll.SPMAsyncTask] (pool-6
Re: [Users] [Pulp-list] unable to remove rpm
damnit yes :-). Sorry!!! :-)
2014-03-25 12:13 GMT+01:00 Yedidyah Bar David :
> Wrong list ? :-)
> --
> Didi
>
> --
>
> *From: *"Koen Vanoppen"
> *To: *"Alex Leonhardt" , users@ovirt.org
> *Sent: *Tuesday, March 25, 2014 1:08:10 PM
> *Subject: *Re: [Users] [Pulp-list] unable to remove rpm
>
>
>
> You have this error after you have removed the rpm? If it is possible for
> you, could you lpease try to restart your server? And check again.
>
> Kind regrads
>
>
> 2014-03-25 11:29 GMT+01:00 Alex Leonhardt :
>
>> Aha, seems to be gone now - or at least it's no longer on the webpage,
>> but when I run publish on that repo again - I get this now:
>>
>>
>> +--+
>> Publishing Repository [#reponame#]
>> +--+
>>
>> This command may be exited by pressing ctrl+c without affecting the actual
>> operation on the server.
>>
>> Publishing packages...
>> [==] 100%
>> Packages: 5/5 items
>> Individual errors encountered during publishing:
>>
>> An unexpected error has occurred. More information can be found in the
>> client
>> log file ~/.pulp/admin.log.
>>
>>
>> admin.log:
>> TypeError: list indices must be integers, not str
>> 2014-03-25 10:22:32,280 - ERROR - Client-side exception occurred
>> Traceback (most recent call last):
>> File "/usr/lib/python2.6/site-packages/pulp/client/extensions/core.py",
>> line 478, in run
>> exit_code = Cli.run(self, args)
>> File "/usr/lib/python2.6/site-packages/okaara/cli.py", line 966, in run
>> exit_code = command_or_section.execute(self.prompt, remaining_args)
>> File
>> "/usr/lib/python2.6/site-packages/pulp/client/extensions/extensions.py",
>> line 224, in execute
>> return self.method(*arg_list, **clean_kwargs)
>> File
>> "/usr/lib/python2.6/site-packages/pulp/client/commands/repo/sync_publish.py",
>> line 221, in run
>> status.display_task_status(self.context, self.renderer, task_id)
>> File
>> "/usr/lib/python2.6/site-packages/pulp/client/commands/repo/status/status.py",
>> line 41, in display_task_status
>> _display_status(context, renderer, task_list)
>> File
>> "/usr/lib/python2.6/site-packages/pulp/client/commands/repo/status/status.py",
>> line 95, in _display_status
>> _display_task_status(context, renderer, task.task_id,
>> quiet_waiting=quiet_waiting)
>> File
>> "/usr/lib/python2.6/site-packages/pulp/client/commands/repo/status/status.py",
>> line 122, in _display_task_status
>> renderer.display_report(response.response_body.progress)
>> File
>> "/usr/lib/python2.6/site-packages/pulp_rpm/extension/admin/status.py", line
>> 74, in display_report
>> self.render_packages_step(progress_report)
>> File
>> "/usr/lib/python2.6/site-packages/pulp_rpm/extension/admin/status.py", line
>> 282, in render_packages_step
>> render_itemized_in_progress_state(self.prompt, data, _('packages'),
>> self.packages_bar, state)
>> File
>> "/usr/lib/python2.6/site-packages/pulp_rpm/common/status_utils.py", line
>> 119, in render_itemized_in_progress_state
>> error_msg = error['error']
>>
>>
>> I also did another
>>
>> $ pulp-admin orphan remove --all
>> Request accepted
>>
>> and tried to publish again, with the same result/s.
>>
>>
>>
>> Alex
>>
>>
>>
>>
>>
>>
>> On 25 March 2014 10:09, Koen Vanoppen wrote:
>>
>>> What happens when you remove the file from /var/lib/pulp/content/rpm/ ?
>>>
>>> Just an idea...
>>>
>>> Kind regards,
>>>
>>> Koen
>>>
>>>
>>> 2014-03-25 10:47 GMT+01:00 Alex Leonhardt :
>>>
hi,
for some odd reason i've stopped being able to remove a RPM from one of
our repositories - the actions / checks seem to be returning OK although
the RPM is not being removed.
STR:
login to pulp with
$ pulp-admin login -u admin -p therealpassword
remove the rpm with
$ pulp-admin rpm repo remove rpm --repo-id #reponame# --match
filename=#fullfilename#
Output:
Progress on this task can be viewed using the commands under "repo
tasks".
check progress with
$ pulp-admin repo tasks list --repo-id #reponame#
Output:
+--+
Tasks
+--+
Operations: unassociate
Resources: #reponame# (repository)
State: Successful
Start Time: 2014-03-25T09:42:19Z
Finish Time: 2014-03-25T09:42:19Z
Result: N/A
Task Id: 4c8f6ea7-eedd-46fe-bf58-6bc0824ed3fc
check if rpm is now orphaned:
$ pulp-admin orphan list --details
+--+
Summary
+---
Re: [Users] [Pulp-list] unable to remove rpm
You have this error after you have removed the rpm? If it is possible for
you, could you lpease try to restart your server? And check again.
Kind regrads
2014-03-25 11:29 GMT+01:00 Alex Leonhardt :
> Aha, seems to be gone now - or at least it's no longer on the webpage, but
> when I run publish on that repo again - I get this now:
>
>
> +--+
> Publishing Repository [#reponame#]
> +--+
>
> This command may be exited by pressing ctrl+c without affecting the actual
> operation on the server.
>
> Publishing packages...
> [==] 100%
> Packages: 5/5 items
> Individual errors encountered during publishing:
>
> An unexpected error has occurred. More information can be found in the
> client
> log file ~/.pulp/admin.log.
>
>
> admin.log:
> TypeError: list indices must be integers, not str
> 2014-03-25 10:22:32,280 - ERROR - Client-side exception occurred
> Traceback (most recent call last):
> File "/usr/lib/python2.6/site-packages/pulp/client/extensions/core.py",
> line 478, in run
> exit_code = Cli.run(self, args)
> File "/usr/lib/python2.6/site-packages/okaara/cli.py", line 966, in run
> exit_code = command_or_section.execute(self.prompt, remaining_args)
> File
> "/usr/lib/python2.6/site-packages/pulp/client/extensions/extensions.py",
> line 224, in execute
> return self.method(*arg_list, **clean_kwargs)
> File
> "/usr/lib/python2.6/site-packages/pulp/client/commands/repo/sync_publish.py",
> line 221, in run
> status.display_task_status(self.context, self.renderer, task_id)
> File
> "/usr/lib/python2.6/site-packages/pulp/client/commands/repo/status/status.py",
> line 41, in display_task_status
> _display_status(context, renderer, task_list)
> File
> "/usr/lib/python2.6/site-packages/pulp/client/commands/repo/status/status.py",
> line 95, in _display_status
> _display_task_status(context, renderer, task.task_id,
> quiet_waiting=quiet_waiting)
> File
> "/usr/lib/python2.6/site-packages/pulp/client/commands/repo/status/status.py",
> line 122, in _display_task_status
> renderer.display_report(response.response_body.progress)
> File
> "/usr/lib/python2.6/site-packages/pulp_rpm/extension/admin/status.py", line
> 74, in display_report
> self.render_packages_step(progress_report)
> File
> "/usr/lib/python2.6/site-packages/pulp_rpm/extension/admin/status.py", line
> 282, in render_packages_step
> render_itemized_in_progress_state(self.prompt, data, _('packages'),
> self.packages_bar, state)
> File "/usr/lib/python2.6/site-packages/pulp_rpm/common/status_utils.py",
> line 119, in render_itemized_in_progress_state
> error_msg = error['error']
>
>
> I also did another
>
> $ pulp-admin orphan remove --all
> Request accepted
>
> and tried to publish again, with the same result/s.
>
>
>
> Alex
>
>
>
>
>
>
> On 25 March 2014 10:09, Koen Vanoppen wrote:
>
>> What happens when you remove the file from /var/lib/pulp/content/rpm/ ?
>>
>> Just an idea...
>>
>> Kind regards,
>>
>> Koen
>>
>>
>> 2014-03-25 10:47 GMT+01:00 Alex Leonhardt :
>>
>>> hi,
>>>
>>> for some odd reason i've stopped being able to remove a RPM from one of
>>> our repositories - the actions / checks seem to be returning OK although
>>> the RPM is not being removed.
>>>
>>> STR:
>>>
>>> login to pulp with
>>> $ pulp-admin login -u admin -p therealpassword
>>>
>>> remove the rpm with
>>> $ pulp-admin rpm repo remove rpm --repo-id #reponame# --match
>>> filename=#fullfilename#
>>> Output:
>>> Progress on this task can be viewed using the commands under "repo
>>> tasks".
>>>
>>> check progress with
>>> $ pulp-admin repo tasks list --repo-id #reponame#
>>> Output:
>>> +--+
>>> Tasks
>>> +--+
>>>
>>> Operations: unassociate
>>> Resources: #reponame# (repository)
>>> State: Successful
>>> Start Time: 2014-03-25T09:42:19Z
>>> Finish Time: 2014-03-25T09:42:19Z
>>> Result: N/A
>>> Task Id: 4c8f6ea7-eedd-46fe-bf58-6bc0824ed3fc
>>>
>>> check if rpm is now orphaned:
>>> $ pulp-admin orphan list --details
>>> +--+
>>> Summary
>>> +--+
>>>
>>> Total: 0
>>>
>>> ok, so lets try and re-publish the repo and check again
>>>
>>> $ pulp-admin rpm repo publish run --repo-id=#reponame#
>>> +--+
>>> Publishing Repository [#reponame#]
>>> +--+
>>>
>>> This command may be exited by pressing ctrl+c without affecting the
>>> actual
>>> op
Re: [Users] oVirt 3.5 planning
Hi, as Dan told me I'm gonna add one more feature request: IPv6 Support for engine and compute nodes, so you are able to use oVirt in an IPv6 only environment. Currently ComputeNodes require their own IPv4 address. I don't know if and what upstream dependencies might exist but I think it is worth the effort, not speaking of getting into some mainline distributions. (AFAIK Fedora has a policy that all daemons which are facing the network must support IPv6 ?) It is the year 2014, we are running out of IPv4 addresses world wide. Every new product like oVirt should try it's best to support IPv6 in general. A second feature: Fencing Hosts from engine, I already created a BZ for this one: https://bugzilla.redhat.com/show_bug.cgi?id=1054778 In fact, it's target release was already set to 3.5 but that doesn't always mean it will make it ;) This feature would really be helpful for local storage DCs. If I had to decide which one gets in I'd want the fencing from engine. Am 24.02.2014 17:59, schrieb Itamar Heim: > with oVirt 3.4 getting close to GA with many many great features, time > to collect requests for 3.5... -- 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] Instructions to add a remote controlled power strip not in the native list?
- Original Message - > From: "David Smith" > To: "Eli Mesika" > Cc: "Marek Grac" , "users" , "Yedidyah Bar > David" > Sent: Tuesday, March 25, 2014 3:04:53 AM > Subject: Re: [Users] Instructions to add a remote controlled power strip not > in the native list? > > All right, serious progress. Thanks to all for your nudges in the right > direction. > I've managed to get my ovirt to recognize and use the agent. > I have a new problem however > > I get this message when the fence_raritan agent is run: Ignoring unknown > option 'option=status' fence > So it appears that my fence_raritan agent is being sent "--option" instead > of "--action" > > Since the default behavior is "reboot" (fence_raritan expects --action= not > --option=) the systems reboot every time a status request is sent :( hehe > > Related:? https://bugzilla.redhat.com/show_bug.cgi?id=987446 > I'm not using "concurrent" Not related > > So the question is, does anyone here know what the best course of action to > resolve this issue is? My host machines are running centos 6.5. > Is this problem within a fencing package, ovirt, or other? AFAIK this is related to http://gerrit.ovirt.org/#/c/24343/ which changed --option to --action danken ? > > I tried to set option=action in the engine database, but it appears theres > probably only a few (3?) mappings possible there, unless I'm wrong and > there are more? > > > This is what I've changed for now, using 3.3 cluster; > UPDATE "vdc_options" SET > option_value='apc:secure=secure,port=ipport,slot=port;apc_snmp:port=port;bladecenter:secure=secure,port=ipport,slot=port;cisco_ucs:secure=ssl,slot=port;drac5:secure=secure,slot=port;eps:slot=port;ilo:secure=ssl,port=ipport;ipmilan:;ilo2:secure=ssl,port=ipport;ilo3:;ilo4:;rsa:secure=secure,port=ipport;rsb:;wti:secure=secure,port=ipport,slot=port;raritan:slot=port,port=ipport;' > where option_id=389; > > UPDATE "vdc_options" SET > option_value='apc,apc_snmp,bladecenter,cisco_ucs,drac5,eps,ilo,ilo2,ilo3,ilo4,ipmilan,rsa,rsb,wti,raritan' > where option_id=395; > > > On Mon, Mar 24, 2014 at 2:07 PM, Eli Mesika wrote: > > > > > > > - Original Message - > > > From: "David Smith" > > > To: "Eli Mesika" > > > Cc: "Marek Grac" , "users" , > > "Yedidyah Bar David" > > > Sent: Friday, March 21, 2014 4:33:17 PM > > > Subject: Re: [Users] Instructions to add a remote controlled power strip > > not in the native list? > > > > > > Hey guys, > > > > > > I submitted an initial agent for raritan to the fence-agents group, > > however > > > I have a feeling after experimenting with the ipmilan agent that my agent > > > won't work with oVirt; > > > > Can you please elaborate on that ? what will not work and why this is > > related to the ipmilan card ? > > > > > > > > Is the command set for each agent determined by the oVirt database > > itself, > > > in other words, when I add the agent the abilities are then added? > > > > Please see http://www.ovirt.org/Custom_Fencing for the exact set of > > fields in database involved in that. > > If you are implementing raritan PM agent , you should have fence_raritan > > in /usr/sbin of the host that is selected as a proxy for the fencing > > operation, you should also make sure that this script has similar > > permissions as other scripts bundled with the fence-agents RPM > > > > > > > > For example the agent I submitted only has support for connectivity > > > settings and power on/off/reboot as well as some delays. Also currently > > it > > > requires that the port be specified as a path ie /system1/outlet1 > > > > > > Will this work as an outlet path? > > > > You can try to put that in the options field in the UI for the PM agent > > definition , i.e "port=/system1/outlet1" > > > > > Minimum commands required to work? > > > > Not sure I go you here , please elaborate/explain > > > > > > > > Thanks > > > > > > ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] 3.4 GA
Thanks. Worth the wait. I like the improvements -Original Message- From: Itamar Heim [mailto:ih...@redhat.com] Sent: Tuesday, March 25, 2014 2:19 AM To: Maurice James; users@ovirt.org Subject: Re: [Users] 3.4 GA On 03/24/2014 07:47 PM, Maurice James wrote: > Did 3.4 GA get released yet? not yet. we need an issue in vdsm/node resolved. you can try RC2 if not using node. ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
[Users] Little issue
Dear All, My engine.log file continues to give the following error: 2014-03-25 10:04:55,381 WARN [org.ovirt.engine.core.vdsbroker.VdsManager] (DefaultQuartzScheduler_Worker-35) Failed to refresh VDS , vds = 497c0af3-4897-46f4-bffa-049bcd0ae713 : buran, error = java.lang.NullPointerException, continuing.: java.lang.NullPointerException 2014-03-25 10:05:10,705 WARN [org.ovirt.engine.core.vdsbroker.VdsManager] (DefaultQuartzScheduler_Worker-42) Failed to refresh VDS , vds = 497c0af3-4897-46f4-bffa-049bcd0ae713 : buran, error = java.lang.NullPointerException, continuing.: java.lang.NullPointerException 2014-03-25 10:05:25,945 WARN [org.ovirt.engine.core.vdsbroker.VdsManager] (DefaultQuartzScheduler_Worker-9) Failed to refresh VDS , vds = 497c0af3-4897-46f4-bffa-049bcd0ae713 : buran, error = java.lang.NullPointerException, continuing.: java.lang.NullPointerException 2014-03-25 10:05:41,189 WARN [org.ovirt.engine.core.vdsbroker.VdsManager] (DefaultQuartzScheduler_Worker-72) Failed to refresh VDS , vds = 497c0af3-4897-46f4-bffa-049bcd0ae713 : buran, error = java.lang.NullPointerException, continuing.: java.lang.NullPointerException 2014-03-25 10:05:56,449 WARN [org.ovirt.engine.core.vdsbroker.VdsManager] (DefaultQuartzScheduler_Worker-67) Failed to refresh VDS , vds = 497c0af3-4897-46f4-bffa-049bcd0ae713 : buran, error = java.lang.NullPointerException, continuing.: java.lang.NullPointerException 2014-03-25 10:06:11,763 WARN [org.ovirt.engine.core.vdsbroker.VdsManager] (DefaultQuartzScheduler_Worker-5) Failed to refresh VDS , vds = 497c0af3-4897-46f4-bffa-049bcd0ae713 : buran, error = java.lang.NullPointerException, continuing.: java.lang.NullPointerException 2014-03-25 10:06:27,164 WARN [org.ovirt.engine.core.vdsbroker.VdsManager] (DefaultQuartzScheduler_Worker-49) Failed to refresh VDS , vds = 497c0af3-4897-46f4-bffa-049bcd0ae713 : buran, error = java.lang.NullPointerException, continuing.: java.lang.NullPointerException 2014-03-25 10:06:42,463 WARN [org.ovirt.engine.core.vdsbroker.VdsManager] (DefaultQuartzScheduler_Worker-76) Failed to refresh VDS , vds = 497c0af3-4897-46f4-bffa-049bcd0ae713 : buran, error = java.lang.NullPointerException, continuing.: java.lang.NullPointerException 2014-03-25 10:06:57,814 WARN [org.ovirt.engine.core.vdsbroker.VdsManager] (DefaultQuartzScheduler_Worker-1) Failed to refresh VDS , vds = 497c0af3-4897-46f4-bffa-049bcd0ae713 : buran, error = java.lang.NullPointerException, continuing.: java.lang.NullPointerException 2014-03-25 10:07:13,167 WARN [org.ovirt.engine.core.vdsbroker.VdsManager] (DefaultQuartzScheduler_Worker-49) Failed to refresh VDS , vds = 497c0af3-4897-46f4-bffa-049bcd0ae713 : buran, error = java.lang.NullPointerException, continuing.: java.lang.NullPointerException 2014-03-25 10:07:28,504 WARN [org.ovirt.engine.core.vdsbroker.VdsManager] (DefaultQuartzScheduler_Worker-81) Failed to refresh VDS , vds = 497c0af3-4897-46f4-bffa-049bcd0ae713 : buran, error = java.lang.NullPointerException, continuing.: java.lang.NullPointerException 2014-03-25 10:07:43,887 WARN [org.ovirt.engine.core.vdsbroker.VdsManager] (DefaultQuartzScheduler_Worker-93) Failed to refresh VDS , vds = 497c0af3-4897-46f4-bffa-049bcd0ae713 : buran, error = java.lang.NullPointerException, continuing.: java.lang.NullPointerException 2014-03-25 10:07:59,305 WARN [org.ovirt.engine.core.vdsbroker.VdsManager] (DefaultQuartzScheduler_Worker-90) Failed to refresh VDS , vds = 497c0af3-4897-46f4-bffa-049bcd0ae713 : buran, error = java.lang.NullPointerException, continuing.: java.lang.NullPointerException Over and over again... Any ideas? Kind regards, Koen ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] Correct way to change graphics adapter?
On 03/25/2014 09:37 AM, mad wrote: Am 24.03.2014 23:20, schrieb Itamar Heim:> On 03/24/2014 08:04 AM, mad wrote: What is the proper way to change the graphics adapter of a VM? I know that oVirt uses qemu and I know qemu configuration, but where in oVirt do I change it? I found VDSM-Hooks/qemucmdline, but that can't be the correct way? Can I change the qemu xml somewhere? can you please explain the use case? We have software developers who need VMs to test their software and for some test a display of 1280x1024 is necessary. The default cirrus graphics card is not good enough for that. But we have some VMs which use a Red Hat Virtual graphics adapter and we don't know how this happened or how it is configured. We just figured out that the difference may be connecting with SPICE or VNC. Is there a different way to change the grapics card permanently? You just have to install the QXL drivers in your vm and connect via SPICE. I didn't test it in oVirt but in RHEV there's no need to change the graphics adapter, just install the QXL drivers, as guests fall back from QXL graphics card to standard VGA graphics card if the driver is missing. You can find the QXL drivers here: http://www.spice-space.org/download.html Regards, René Thanks, mad ___ 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] Correct way to change graphics adapter?
Am 24.03.2014 23:20, schrieb Itamar Heim:> On 03/24/2014 08:04 AM, mad wrote: >> What is the proper way to change the graphics adapter of a VM? I know >> that oVirt uses qemu and I know qemu configuration, but where in oVirt >> do I change it? >> >> I found VDSM-Hooks/qemucmdline, but that can't be the correct way? >> >> Can I change the qemu xml somewhere? > > can you please explain the use case? We have software developers who need VMs to test their software and for some test a display of 1280x1024 is necessary. The default cirrus graphics card is not good enough for that. But we have some VMs which use a Red Hat Virtual graphics adapter and we don't know how this happened or how it is configured. We just figured out that the difference may be connecting with SPICE or VNC. Is there a different way to change the grapics card permanently? Thanks, mad ___ 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" > To: "Yedidyah Bar David" > Cc: "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
