Posts made by Andrew

@McHenry Correct, my DR server is not part of the main pool. The main pool has several hosts and shared storage (NFS) and if one host fails there's room for guest VMs on another host in the pool. If main storage totally fails then the VMs could be run on the DR system and then migrated back to the main pool when operational.

The DR server is a form of an active backup as it does not share storage with the main pool (it has its own SSD RAID6). There are other real backups (offsite S3 and separate OS level backups).

@Teddy-Astie Yes...

@Buckle8711 I see that too. QEMU is only started with two interfaces passed to the guest. I don't know if that's because of the lack of tools or native drivers or some other config issue.

@olivierlambert XCP/Xen/Qemu expert question: Why does qemu start with only two interfaces when more are configured in XO?
qemu-dm-7 -machine pc-i440fx-2.10,accel=xen ... -device e1000,netdev=tapnet1,mac=5a:7f:c3:ba:04:d6,addr=5,rombar=0 -netdev tap,id=tapnet1,fd=7 -device e1000,netdev=tapnet0,mac=8e:68:02:55:da:c7,addr=4,rombar=0 -netdev tap,id=tapnet0,fd=8 ...
Where's the third and fourth? I see other VMs with more. Is it a template or vm-param issue?

@stormi Installed on several test and pre-production machines.

@gduperrey Installed and running on active pools.

@knut99 Note for the UH125, it uses the RTL8126 ethernet chip. While it may work with XCP, it's officially not supported due to the Realtek drivers.

@Buckle8711 No guest tools.... OpenSolaris does include Xen drivers but I don't know if they have been updated. I don't seem them loading.

@Buckle8711 It boots just fine for me with XCP 8.3... with the same PCI Warning... And the notices are not errors, so it works (I don't have the notices on my VM).

@McHenry Look at this post: VM limits - CPU Limits

@McHenry Is DR a 4 core+4 HT? or 8 core (no HT)?

If you have HT disabled in DR you could enable it (but that only gives you 16). If you truly only have a 4 core CPU then how well will the application work on a 4 core CPU vs 32 core system?

Looks like you need a better DR machine, or will the application never run on the DR site and it's just for checking that a backup starts? In that case a XO mod would be helpful to change the settings for a health check.

@vmpr Put your cert first and then the intermediate cert in a single file.

@McHenry Yes, XCP sees and uses all threads (8 core + SMT x2 threads = 16 logical cores). So you can assign all of them to a VM as long as the VM can use them.

XO shows 16 "cores" (total threads) and 1 socket. It also shows hyperthreading is enabled. XCP/XO does not differentiate between cores, threads, E-Cores or P-Cores.....a thread is an assignable core resource.

You can assign 16 logical vCPU that includes real cores and SMT threads.

Some programs do not work well with hyperthreading in a VM environment. So you may wish to disable SMT depending on the workload.

@McHenry You just need to add more memory to the DR host... You could use Dynamic VM memory, but it's strongly recommended that you don't, partly for this reason. If you allocate 8-16G memory and then move or start the VM on a host with fewer resources then the VM may fail so you need more host memory anyway. Static memory allocation prevents VM failures, the VM works as expected or won't start.

Most DR sites "cheat" by having fewer total resources then all the clients. This became a problem in the US on 9/11 as there was a massive simultaneous call for DR activation. Now days there is 1:1 DR that costs a lot or oversubscribed DR that costs less. Many places go for active/active sites to split the load and provide redundancy rather than having a warm DR site (or just stuff it in the cloud and work from home).

@McHenry Dom0 (control domain) is normally 2-16Gigs, or about 10% of total memory. There's other system memory needed too. The XCP install picks a reasonable value for most uses.

Yes, Dom0 uses part if your total system RAM. So if you have 32G and assign 4 Gigs to Dom0 you'll have less than 28G for VMs. That means you can start one 16G VM but not two. If you have a second host with only 16G then you can't start that 16G VM because Dom0 would need some of that memory.

If you have a pool of machines with different sizes of memory this can be an issue because a VM may not be able to run on all hosts in the pool.

@McHenry Minimal effect on having more sockets but less cores. Keep it simple.

If your license limits you to 1 socket and 4 cores, then 1 socket and 4 cores is what you use. 1 socket an 8 cores is greater than the 4 core limit.

For the 4 socket/24 core limit you could still use 1 socket and 24 cores (or 1 socket and 8 cores, or 2 sockets and 12 cores each, or 4 sockets and 6 cores each). But you can't use 6 sockets and 4 cores each because that's over the limit.

The math has to work out to support your system. You can't have 4 sockets and 4 cores if you only have 8 cores in your system (or threads, but then you have to look at the SMT notes about hyperthreading).

You can have more VMs with allocated cores than your system actually has (like 4 VMs with 4 cores each, on an 8 core host), but a single VM can't have more cores allocated then the host actually has (like 16 cores in a VM on an 8 core host).

I think the optimal assignment is to use the template default or the number of sockets your host has (or less) and then assign the number of cores you need. There's a whole NUMA issue that Xen tries to work out between the host and the guest. If you go into SQL optimization then you might want to pin CPUs for the VMs for best performance. If you have a single socket system then just use one socket and the number of cores you want. If you have a pool then watch out for the minimum system specs (ie. you can't migrate a 16 core VM from a 24 core host to an 8 core host).

@gduperrey Single 8.2.1 hosts and pools updated. All running fine. VMs working, CR CBT/NBD backup working.

@McHenry You can allocate more vCPUs than real CPUs. If a VM is single threaded bound then adding more vCPUs won't make it faster and also won't slow down other VMs. If you allocate more vCPUs and they are all busy then all VMs will slow down because they share CPU cores.

Unless you do something special then VMs allocated vCPUs that don't use them won't really interfere with other VMs that need CPU time that share vCPUs.

Remember Dom0 also has vCPUs allocated and will share time with VMs.

@Affonso Looks like it might have been Bug 15684 in 24.03 that was resolved for 24.11 (release notes).

@nullstream-0 Correct, OpenBSD 7.6 does not correctly recognize and use all the Xen PV devices and therefore uses the hardware emulated devices for both disk and network.

@McHenry As an example.... I use CR hourly for the main pool onto a backup host that has lots of storage and the same networks. It's a quick DR server that can start an VM (or a clone) immediately if the main pool fails or a VM becomes so corrupt that it needs to be restored from backup. But this is not a long term backup solution, it's an immediate restore solution. CR does an hourly delta update and a weekly full update just to make sure the data is always clean. You can think of CR as an off-host snapshot, and you don't want to keep too many around. To be clear, I don't keep ongoing deltas long term, just the current one.

For long term backup I use Wasabi S3 and do delta backups every night. I keep the deltas for about 90 days and do a new full backup about every 3 months. This again is to make sure the delta backup chain does not have a long term corruption. It is possible to restore any VM or any file from any delta (or full) backup along the way.