Manual CPU feature Masks (every CPU is a potato)?
-
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.
Regarding mixing and matching different CPUs within the same pool: do note that you can not mix AMD/Intel together. Different CPU models of the same brand within a pool will work though. And it behaves just like you said: XCP-ng hosts will agree on the least common denominator regarding CPU features and use that across the pool in order to ensure that (live) migrations will work.
-
@MajorP93 I'm pretty sure you can migrate between dissimilar pools as long as the CPU architecture is the same. You can't go from Pool A with AMD to Pool B with Intel, but you should be able to go from Pool A AMD to Pool B AMD with the caveat that the CPU generation of the destination pool has to be equal or beyond that of the source pool.
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.
-
@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,
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.)
-
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.)
On XCP-ng?
-
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).
-
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).
-
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).
Are you sure that the VM isn't being stopped, copied, moved, started (and removed from the old pool).
-
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.)
Okay I assumed that you use shared storage.
From the XenServer 8.4 "Migrate VMs" docs:
"Storage can only be shared between hosts in the same pool. As a result, VMs can only be migrated to hosts in the same pool."So for classic live migrations that do not transfer the virtual disk you have to be on the same pool.
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.
//EDIT: also there is no such thing as non-pool hosts. Even a single host setup has it's own pool.
-
@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.
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login