@florent So If my Mikrotik router is sitting between XO and the HITRON and the HITRON is power cycled, because the Mikrotik is the gateway as far as XO is concerned and the gateway is not down, will the 10 minute timeout apply or might it timeout faster than that?

@comdirect Use this command: (replace sda in the command below with the relevant device) cat /sys/block/sda/queue/scheduler The active scheduler will be enclosed in brackets. e.g. noop deadline [cfq] For multiple drives use: grep "" /sys/block/*/queue/scheduler

Difficile de parler de « réalité » avec les benchmarks. Vérifiez aussi l'iodepth (qui dépend du type matériel que vous avez, sur du flash/NVMe vous pouvez monter à 128 ou 256), la latence entre en compte aussi bien sûr. Le bottleneck principal est le monothreading de tapdisk, si vous testez sur plusieurs VMs différentes la somme va monter de manière assez régulière.

@User-cxs You are probably experiencing this issue. Just a guess because you didn't actually ask a question.

https://xcp-ng.org/forum/topic/11951/just-fyi-current-update-seams-to-break-nut-dependancies

@olivierlambert done.

Having help from OpenBSD side could be the way to go. Please forward your report to bugs@openbsd.org (with a link to this post too) For the record, I am able to reproduce it too (on XCP-ng 8.3 too, using OpenBSD -current).

@DustinB doesn't it use the exact same mechanism? I have to find out.

@olivierlambert said: I think it was fixed since, are you sure you are using an uptodate XO? Commit 0be23 Anyway was directing attention to the GitHub issue, which was opened. The issue has another reference to it.

thanks Andryi We us round robin when using NBD , but to be fair, it does not change the performance a lot in most of the case. The concurrency settings ( multiple connection to the same file ) is helping when there is a high latency between XO and the host. SO , @fcgo if you have thousand of VMs , you should enable NBD it will consume less resource on the DOM0 and XO , and it will be spread on all the possible hosts.

That's a very good question, let me ask internally. Ping @pdonias he might know the answer

@bleader thanks for the tip. You see my knowledge in redhat based systems is almost non existant. Think I'm almost 99% debian and 1% ubuntu (and that not by choice) So I will take care of redeploying the script as soon as I upgrade, should be easily noticeable since monitoring will loose access and yell at me.

@olivierlambert said in Rust-based guest-tools... How are things going?: The thing is that it works very well and doesn't need fixes… I know, not usual right? It was so stable that we left it like that waiting for people coming for bugs and nothing happened… We'll cut a 1.0 in the next weeks/months. I have indeed seen the stability of it myself. But the lack of updates made me worry anyway. But I'm really looking forward to the promotion to 1.0 as well. Thanks!

@acebmxer welcome to freedom.

@kruess I can see numerous instances of VM_HOST_INCOMPATIBLE_VERSION in your xensource log. It is difficult to know the exact cause ithout more details. Was the pool master restarted after the patches were applied? Are you trying to start the VM on the master? Are you upgrading directly from XS 7.1.2 to XCP 8.3?

502 is an answer coming from your S3, telling the server is having an issue. Adding @florent in the loop

Good question! Ping @pdonias I assume

@ItzJay in your journalctl -i xo-server log you should have something like nbdkit logs of ${diskPath} are in ${tmpDir} where tmpDir is something like /tmp/xo-serverXXXX/stderr can you post the file ? alternatively, you can open a support ticket

Version 1.4.0 is released: https://codeberg.org/NiXOA/system/releases/tag/v1.4.0 It includes significant changes and improvements, including: dedicated getting started section, migration to valkey, only needing to clone system, and helper scripts. the xen-orchestra-ce nixpkg now references the libvhdi nixpkg, and the core flake now references and pulls from the xen-orchestra-ce repo as an overlay. System (the user input flake) now uses the Core repo as an overlay, reducing the need to clone both locally AND allowing system to pull new updates and releases from core. XO, and libvhdi as needed. The next goal is: Make an xsconsole-like TUI Automate package updates for libvhdi and xen-orchestra-ce using CI/CD pipelines Submit libvhdi and xen-orchestra-ce as official nixpkgs

@benapetr said in Import from VMware err: name: AssertionError: Expected "actual" to be strictly unequal to: undefined: Hello, since this never had a clear resolution, here is explanation of the bug and why it happens: There is a bug in disk iteration in that XO vmware plugin (somewhere in that esxi.mjs I don't remember exact location) - it basically expects that all disks of VM exist in same datastore and if they don't it crashes as the next disk in unexpectedly missing (undefined) Workaround is rather simple - select the VM in vmware, migrate -> storage, disable DRS (important) and then select any DS that no disks current exist on. If you select and DS that is already used by same VM it will sometimes not get fixed! It also may happen even if VM is "apparently" looking like it's on single DS, even if it reports as such, still try to migrate it to another DS, and disable DRS so that really all files, even meta files are in same directory. Then run XO import again, it will magically work. thanks you for the input we were under the assumption that all the disk of a VM are in the same datastore the fix should be too hard now that you did the hard work edit: card created in our backlog, I will take a look after the release to see how hard it is to implement