@Cyrille

@olivierlambert It's even older than that. https://github.com/vatesfr/xen-orchestra/blob/master/CHANGELOG.v5.md#5540-2020-12-29 https://xen-orchestra.com/blog/xen-orchestra-5-54/

@benapetr you seem gifted with app development. do you know RV Tools ? https://www.dell.com/support/kbdoc/en-us/000325532/rvtools-4-7-1-installer this tool is pretty handy when auditing VMWARE infrastructures, it can connect to vcenter or directly to ESXi and full dump in csv/xlsx the infrastructure configuration (all aspects of the config, be it VM, hosts, networks, datastores, files, ...) I could see a real production use of same tool, but for XCP Pools/XCP hosts would be a great add to XenAdmin !

Instruction published: https://docs.xen-orchestra.com/sdn_controller#openssl-3--sdn-upgrade-path Any volunteer to test this along upcoming XCP-ng update ?

@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

@tmnguyen You can open a support ticket and request that we reactivate your XOSTOR trial licenses to match your existing XOA trial.

Hi @olivierlambert, Finally got round to following up on this. I found a better solution using DEFAULT_CHUNK_SIZE, which is normally set to 4MB, with MAX_PART_NUMBER being 1000, this limits the largest object backed up to 3rd party S3 implementations as 4GB. Increasing the DEFAULT_CHUNK_SIZE in the S3 code, or having a setting in configuration, either file or web GUI would allow backups of VMs larger than 4GB, without the memory required to track several thousand object chunks. Regards, Mark

Hello, I have hardware issues, specially on the disks. Unfortunately I don't have fully access to the machine to be able to confirm if is effectively disks( more likely ) or back-plane. Interestingly some of those VMs does work, I can boot them and work with them but cannot copy the disks. Since those are Windows server VM I have also tried the Windows backup tool and this failed as well to perform to finish the backup. So I'm closing this investigation as hardware issue.

Hi, does anyone have any tips regarding getting the serial port to show up in xcp-ng? I imagine this normally should just work.. I am not sure why it doesnt show up in xcp-ng, while it shows enabled in the bios?

@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