You cannot share the same LUN between different pools (butyou can share the same SAN with different LUNs)
CEO
Private
Posts
-
RE: Homogeneous pools, how similar do the CPUs need to be?
-
RE: Homogeneous pools, how similar do the CPUs need to be?
- Yes you can
- All VMs booted after the join won't use the most recent CPU features that you don't have on your old CPUs.
The only trick is for previously existing VMs with recent CPU: you need to shutdown then start then again to be sure they aren't using those features (features are applied on boot). So it's doable, but both options are possible.
-
RE: VDI not showing in XO 5 from Source.
@anthoineb or someone from the @team-storage, you might want to take a look (IDK if it's a known problem internally)
-
RE: backup mail report says INTERRUPTED but it's not ?
@Pilow Thanks, it's promising but we'll wait for more runs on your side
If it's that, at least it's not a biggie in the end! -
RE: adding a new VIF in XO doesn't UP the the interface on Debian13
Hi,
Adding a VIF is like plugging "live" a new network card in a physical system. It's still up to your operating system to handle it. XCP-ng doesn't know what's inside a VM, it's up to the VM OS to do what it has to do (like on a regular physical hardware system).
-
RE: VM Pool To Pool Migration over VPN
Hi!
@team-storage will correct me but on top of my head:
- Live migration needs to continue to write locally while the VM runs while copying the blocks on destination. This takes some ressources and time, limiting the transfer speed
- Migration in general is limited by the Dom0 expert speed via tapdisk, which is a bottleneck. In real life, this allowed us to have migrations without disrupting day-to-day operations (not taking all IOPS), which is good for stability but not on purpose
- Copy with compression is faster because all blocks are compressed so you are sending more data for the same time (therefore, faster) at the cost of more CPU cycles. Which in general is worth it, as you've seen.
