Tackyone

@MajorP93 said:
What you are describing must be a storage live migration then (XenMotion). That should work across pools, yes. I stand corrected because I did not factor in this variant in my initial answer.

Yes, that's it - sorry - I should have been more explicit, even if 'lumbers along' wasn't a hint

//EDIT: also there is no such thing as non-pool hosts. Even a single host setup has it's own pool.

Pedantic, but true I technically meant 'not hosts in the source pool' I guess.

@DustinB said:

But we do that all the time? - i.e. Two non-pool hosts, live migrate between them (these happen to have the same CPU / family etc.)

On XCP-ng?

Yes. All the time, from memory it's always been possible (well, maybe not 'always' depending on how far you go back) - but certainly as long as I can remember (considering we've been Xen since I think Version 6? - now xcp-ng 8.3).

@JamesG said:

If I understand it right, Tackyone wants to dumb down all VM's to have the least common denominator CPU instructions so he can migrate any guest to any host. I personally think that's a bad direction, but I understand his desire...Pool a bunch of random systems laying around into a common farm. I think that's a bit too low-end of a goal for Vates to spend any time on myself. That seems exclusively homelab to me and counter to moving forward in the industry.

Yes, that's it. It's 'counter to moving forward in the industry' until you can't actually get the machines that make up existing pools / hosts you have to extend them.

Keeping everything 'dumber' would just make life a lot simpler (whether it be home lab, or systems built up over years as they move forward hardware generations).

@MajorP93 said:

@Tackyone said:
live migrates between non-pooled [...]

Hi,

AFAIK this is not possible. Live migration does only work within the same pool. So you can not live migrate VMs to another pool / host that is not part of the pool.

But we do that all the time? - i.e. Two non-pool hosts, live migrate between them (these happen to have the same CPU / family etc.)

@JamesG said:

@Tackyone Even with the current AI-induced hardware crunch, yester-year hardware isn't all that hard to come by. Why not just get a pile of systems that simply match? You'll have predictable and identical performance across the whole farm without any CPU features or enhancements being lost or ignored. Besides, in order for all the XCP-ng hosts to work together they (ideally) need shared storage and they have to have identical network configurations. Otherwise you've got slow migrations and network re-mapping every time you move something.

Just my thought.

I do see your point, but I already have a pile of systems

We already do live migration on same-CPU set stuff, without shared storage - sure it's lumbers a bit, but running a few in parallel isn't so bad. The network side of things takes care of itself - providing the networks are named the same on the hosts you're moving from / to.

It'd just be handy to settle on a single CPU spec for all this - and then not have to worry about either live migrates, or picking up two of the hosts and pooling them.

Hi,

I've got a number of xcp-ng 8.3 machines running - which are mixed CPU's.

I know if I pool them, the system will look at the CPU's - decide on a 'lowest common denominator' feature set - and use that, so that newly started VM's can be live migrated between members (and old ones can be restarted etc. etc.)

I know there are at least some options for manually setting CPU masks to mask features - but is there any way to tell xcp-ng "I want all my CPU's to be potatoes?"

This would be more akin apparently to how ProxMox works - in that all the VM's think they're running on pretty old CPU's (e.g. SSE2, but nothing new & fancy) - this is apparently done to allow live migrates between dissimilar hosts.

I can see disadvantages to this - but from the perspective from having a bunch of dis-jointed xcp-ng hosts on varying CPU's, doing something similar on xcp-ng (even if it has to be done manually) does seem quite appealing - if it gets live migrates between non-pooled, dissimilar CPU hosts working.

Is there any way to do this - i.e. set some kind of 'master mask' on the xcp-ng host, so any VM's that are brought up just see 'potato CPU' - on all the hosts?

Hi,

We use the 'Remote syslog' option with XCP-ng 8.2.1. This has been working well - but recently we patched the pool, rebooted the pool (everything came back ok) - but Remote syslog - doesn't log any more.

If I go into XO and look at the option for the Hosts - on both it's set to the correct IP address.

If I try changing that IP to a different host on the network XO quite correctly said something like "can't use that expect port to be open".

If I change it back to the original host, I've just noticed - it starts working again.

This is a bit annoying (as we've lost days of logs) - anyone else seen similar with that option?

[Before figuring that changing it 'fixes' it - I'd already tested the syslog server was up, and I could send test log entries to it using 'logger' from the XCP-ng's dom0].

Thanks!

@olivierlambert said in file restore on large backups ends in print_req_error: I/O error's:

Yes, that sounds the next step to do Something is wrong during the mount phase. Also check you have enough RAM in your XOA.

Ok, filesystem checks out - as far as I can see having:

• Done full restore of VM from the same Delta image.
• Booted VM, logged in and done 'tar cvf /dev/null *' of the filesystem I'm trying to restore from - which ran to completion without error.

I upped the RAM for XOA from default 2GiB to 16GiB and re-tried - and same result.

I can try yet more RAM if needs be but would hope 16GiB is more than enough?

The console error on XOA is more detailed than my install- so don't know if this helps:

blk_update_request: I/O error, dev loop0, sector 8912912 op 0x00:(READ) flags 0x80700 phys_seg 1 prio class 0

Looks to be the same issue, just reported differently.

You also (on both systems) get kernel chatter about "tasked blocked" (understandable, as it is).

@olivierlambert said in file restore on large backups ends in print_req_error: I/O error's:

That's why you should try on XOA, not the sources. This way, we can see if it's a XO bug or an issue on your local source install

Ok, latest XOA (updated) has the same issue - process dies with loop0 I/O errors logged to console same as my 'from sources' version.

I'm going to do a full restore of the VM spin it up, and do a full filesystem check on it (well as good as ext3/4 can) - just to make 100% sure there's no corruption - as that seems sensible start / relatively easy to do.

@olivierlambert

Sorry - missed the 'XOA' only saw 'latest'... More coffee needed... Off to try.