Posts made by dougs

@gb-123

Yes, I have tried that and it appears to have deleted the tasks.

First I had to register as follows:

# xo-cli --register <URL of XOA> <admin username> <password>

Then:

# xo-cli rest get tasks

which showed a list of tasks IDs.

I verified the IDs with the ID show in the raw log for each of the tasks listed in XOA. Once I figured out which task(s) I wanted to delete, I did the following for each tasks:

# xo-cli rest del <tasks/task ID>

I have not seen an ill effects since I deleted some tasks last August.

Below is a link to removing tasks using xo-cli:
https://help.vates.tech/kb/en-us/31-troubleshooting-and-tips/123-how-to-remove-xo-tasks

@planedrop Our configuration is nonstandard. Our XOA is on a standalone computer-- not in a VM that runs on one of the hosts.

While these tasks are not interfering with normal operations, I'd like to get listed tasks out of the way.

This is what it looks like on the Tasks window:

Hovering the cursor over the Delete icons causes the cursor to display a No symbol so I cannot click the Delete button.

@planedrop Rebooted and the tasks are still there. Oddly enough, it caused one of the two hosts to reboot as well. What the heck?!?

@Danp Yes, still no dice!

Over a period of 2 weeks I experimented with migrating a few machines from a VMware server over to the xcp-ng environment. There are 5 failed XO tasks as a result of those migrations that somehow cannot be deleted. xe task-list does not list these. I've run xe-toolstack-reset to no avail. What do I need to do in order to clear the XO task list?

I'm using the Xen Orchestra Community Edition. I want to change the email address used for the daily XO report but I cannot find it in the CE version.

In the Dashboard Overview tab, there is a button to click in order to send a report to "configured email addresses" but I do not know how to find these. There isn't any email address field in the Users tab. Can someone point me in the right direction?

@olivierlambert
Thanks. I was able to confirm the pool uuid.

@Ajmind-0
Thanks for the script.

How does one enumerate the pool uuid for a given pool? I see what I believe to be the pool uuid right below the title of the pool in the XOA Pool page but I'd like to be sure it is indeed the correct pool uuid. I searched for the correct command but failed. xe something? xe pool-param-get what?

@Ajmind-0
Well, well, I switched to the snmp connection method and it worked just fine. Um...

Thank you for your pointer.

@Ajmind-0
Strange. I'm using UPSTYPE pcnet and the corresponding DEVICE ipaddr:username:password statement. I'm using the exact syntax on all of our FreeBSD servers and they're communicating with the APC management card.

What is your iptables configuration like?

I need to allow traffic between apcupsd on the host and the APC management card. When iptables is disabled, the host can communicate with the management card. However, when iptables is active, communications no longer occur.

I have tried to insert a rule as follows:

ACCEPT   tcp   192.168.xxx.xxx/32   anywhere   tcp dpt:apcupsd state NEW

as the next to last rule in the RH-Firewall-1-INPUT chain. (The IP address belongs to the APC management card.) The rule doesn't allow packets to/from apcupsd.

I am no iptables expert (we use FreeBSD) and I am not familiar with how the iptables rules are structured on the xcp-ng host. It appears to be specially tailored to xcp-ng.

# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
RH-Firewall-1-INPUT  all  --  anywhere             anywhere            

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
RH-Firewall-1-INPUT  all  --  anywhere             anywhere            

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain RH-Firewall-1-INPUT (2 references)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     icmp --  anywhere             anywhere             icmp any
ACCEPT     udp  --  anywhere             anywhere             udp dpt:bootps
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
ACCEPT     udp  --  anywhere             anywhere             ctstate NEW udp dpt:ha-cluster
ACCEPT     tcp  --  anywhere             anywhere             ctstate NEW tcp dpt:ssh
ACCEPT     tcp  --  anywhere             anywhere             ctstate NEW tcp dpt:http
ACCEPT     tcp  --  anywhere             anywhere             ctstate NEW tcp dpt:https
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:21064
ACCEPT     udp  --  anywhere             anywhere             multiport dports hpoms-dps-lstn,netsupport
ACCEPT     tcp  --  192.168.xxx.xxx/32   anywhere             tcp dpt:apcupsd state NEW
REJECT     all  --  anywhere             anywhere             reject-with icmp-host-prohibited
#

Suggestions?

@Ajmind-0 Care to share the shutdown script used to shutdown the VMs and the host?