Offline
@tjkreidl said in Issue with SR and coalesce:
@nikade Am wondering still if one of the hosts isn't connected to that SR properly. Re-creating teh SR from scratch would do the trick, but a lot of work shuffling all the VMs to different SR storage. Might be worth it, of course, if it fixes the issue.
Yeah maybe, but I think there would be some kind of indication in XO if the SR wasn't properly mounted on one of the hosts.
Lets see what happends, its weird indeed that its not shown.
@Byte_Smarter said in Issue with SR and coalesce:
Maybe I am reading this wrong but the SR is not there in a mount? but also it is viewable and working in XO and lists usage and all that?
It should definitely be listed here, I'd start over and see if it shows afterwards.
Remember to fully destroy and remove the SR (which will obviously remove all data) and then re-create it to make sure there's no weird stuff left.
Something feels wrong, it writes to the log that there are 23 VDI's to be deleted on SR with uuid 6eb76845-35be-e755-4d7a-5419049aca87 but you say there's not snapshots.
It doesn't add up or am I missing something? How many VDI's do you have on the SR?
That's weird indeed, I wonder what those 23 VDI's are then.
What is the uuid of this new SR? 6eb76845-35be-e755-4d7a-5419049aca87?
I think you can show them from the cli with the following command:
xe sr-list params=name,uuid
@Byte_Smarter said in Issue with SR and coalesce:
Mar 15 04:06:41 ops-xen2 SMGC: [19269] Found 23 VDIs for deletion:
This is what makes me unsure, are you sure there is no snapshots on any VM's?
@Byte_Smarter said in Issue with SR and coalesce:
@tjkreidl I am not sure if you saw my earlier post, I have several TB of space
Are you sure multipathing is disabled on all hosts in the pool?
Also, could you share a larger portion of the /var/log/SMlog ?
As replied by @dthenot you need to check /var/log/SMlog on all of your hosts to see which one it is failing on and why.
If the storage filled up before this started to happend my guess is that there is something corrupted, if that's the case you might have to clean up manually.
I've had this situation once and got help from XOA support, they had to manually clean up some old snapshots and after doing so we triggered a new coalescale (rescan the storage) which were able to clean up the queue.
Untill that's finished I wouldn't run any backups, since that might cause more problems but also slow down the coalescale process.
We've also experience trouble almost every time we've updated our pools, ever since the old XenServer days and Citrix kind of recommended "manual intervention" because there was no mechanism to check which hosts that were suitable before a VM is migrated.
I think there has been a lot of work done to XOA tho to handle this, but I might've been mistaken, we just ended up re-installing our hosts and setting up a new pool which we then live migrate our VM's over too and scrap the old ones.
VMWare has some kind of logic, which will try to balance the load between the hosts and if you have DRS it will even make sure to balance your hosts automatically during runtime.
Im pretty sure XOA has this logic as well, but XCP-NG center definately doesn't, so avoid it as much as possible.
I don't think that's going to be an issue with Vates, they have ppl in different parts of the world and they're very helpfull.
Reach out to them and link this forum thread, im sure they will be able to get you going even tho you're in Australia.
Never found any resolution to this, some times you're able to "restore" the keyboard by trying to type some different special characters (in my case | or > or <) but it only works some times.
This is super annoying when you're trying to do some basic troubleshooting inside a VM from the console.
Every once in a while we have had the need to deploy a new XOA appliance and it is as simple as others have pointed out, just backup config, setup new XO(A) and then just import config.
Works like a charm, only thing we may have to do is to check the plugins configuration, but nothing else.
+1 for swapping the Broadcom NIC's - We're using only Intel for a numerous of reasons, one being performance issues in the past.
Havent tried Broadcom in like 10 years but I remember a lot of issues with dropped packets and driver problems.
Is the VM on shared storage?
Storage migration is quite slow, but if the VM is on shared storage the migration is usually pretty quick, we've seen about 7Gbit/s on a 10G network with MTU 9000.
@syscon-chrisl OK that's another story, totally weird.
It should totally work if the networking is correct, we've done this at work many times (Migrating from 1G to 10G NIC for example).
@syscon-chrisl OK - So you just changed the mgmt interface to another physical NIC?
That should definately work, did you have any ip configuration on any other interface?
Changing the mgmt interface on a pool is nothing I have good experience from, but on a stand alone host it is rather easy:
Make sure that the new interface is connected and has the correct VLAN, if you're using DHCP it will automatically grab an IP. If not you'll have to go on the console and configure the IP manually after changing the interface.
One thing I learned over the years with XenServer and now XCP-NG:
Don't change anything, if you have a pool all hosts needs to have the same specs on their NIC, make sure to sync the clock with NTP, dont use DHCP and dont mess with iptables or similar since it will mess upp XAPI.
From the error message I'd say you have missed some vital part, like what does a traceroute or ping from the XCP-NG to the host look like? Can you telnet the destination and port?
I know the traceroute binary isn't present but you can install it from epel repo's.
@fred974 said in How to pass MAC address to pfSense VM:
@nikade do you use 2 IP subnet? 1x for xcp-ng management + ssh and another extra that you use for the VMs or is it all 1 single subnet? Also did you requested separate MAC on Hetzner backend or left it as is?
@nikade said in How to pass MAC address to pfSense VM:
We then enabled forwarding on the xcp-ng host and setup the first usable IP as "local" subnet
How did you achieve this? Thank you very much in advance. I really appreciate the feedback..
1 IPv4 on the dom0, the one that came with the server. Then we ordered a /29 IPv4 subnet which is routed to the dom0 IPv4 address.
You then need to setup IPv4 forwarding on the dom0 by editing the sysctl and then setup the 1st usable IPv4 from the /29 IPv4 subnet on an internal interface.
I just created a dummy vlan interface and put it there and that worked fine.
Used Hetzner many times with xcp-ng and pfsense, we ordered a subnet which was routed to the xcp-ng host.
We then enabled forwarding on the xcp-ng host and setup the first usable IP as "local" subnet and then we were able to use the rest of the IP's on our VM's using that first IP as default gateway.
