Subcategories

• Management

  VMs, hosts, pools, networks and all other usual management tasks.
  436 Topics

  3k Posts

  P

  @wilsonqanda tried your workaround on a halted VM, and it worked ! If i snapshot -> disk still invisible delete snapshot - > disk still invisible but if i snapshot --> disk still invisible revert snapshot (with take snapshot option) --> disk APPEAR again delete the two snapshots -> disks still there edit : even without the take snapshot before revert, it is working, tried on another VM
• Advanced features

  ACLs, Self-service, Cloud-init, Load balancing...
  97 Topics

  821 Posts

  P

  @DaleDibbadel Are you running XOA or XO from the sources? Are you up-to-date?
• Backup

  All XO backup features: full and incremental, replication, mirrors...
  446 Topics

  4k Posts

  P

  @Bastien-Nollet nice. I can confirm with the dates of the backup logs that it is since the exact date of beginning of DR job that this problem appears on the two other jobs. when not doing NBD+CBT, the backup & replica jobs keep the "full" snapshot on the VM. DR do not do that, it delete the snapshot. I guess this is a silent failure of the way DR manages its snapshot deletion that could delete the CBT bitmap ? and then, baaam fall back to full on other jobs relying on said bitmap... ? this is a run of the DR job [image: 1767861023293-ed0a138a-bf0a-40d1-b073-5542f9e79d02-image.png] no notion of NBD/CBT in DR job advanced parameters, it treats that differently [image: 1767861114862-6c5e772d-eebb-4918-8f49-4a36cafcf7df-image.png]
• REST API

  Everything related to Xen Orchestra's REST API
  75 Topics

  572 Posts

  L

  @florent, I had to do the same for Xen Orchestra Community Edition. In my case, config.toml already contained the [authentication] section, so adding a separate config.tokenValidity.toml file did not work. Instead, I had to modify the existing config.toml located at /opt/xo/xo-server. In my opinion, it is best to keep defaultTokenValidity set to 30 days as a fallback in case no value is specified. You can then simply increase maxTokenValidity to the duration you prefer. [authentication] defaultTokenValidity = '30 days' # default value of 0.5 years # comment out and increase to 5 years #maxTokenValidity = ' 0.5 year' maxTokenValidity = '5 year'
• Infrastructure as Code

  Terraform, Packer or any tool to do IaC
  48 Topics

  436 Posts

  P

  Hi, We stumbled upon what I would call a lack of check.. or a bug ? You can create a VDI of a VM in an ISO shared SR... We did it unexpectedly. .rpc("disk.create", { name, size, sr, vm: vm.id, bootable: false, mode: "RW", }) disk.create name=<string> size=<integer|string> sr=<string> [vm=<string>] [bootable=<boolean>] [mode=<string>] [position=<string>] create a new disk on a SR this is permitted, it should not ? it was a 50Gb CIFS ISO SR, and we could create a 100GB VDI, appearing as a 100GB .img file in the SR [image: 1767881811655-69b097b3-9c28-4b97-982a-34443a199bf1-image.png] [image: 1767881827248-58d0ca02-d1be-4d49-a4bd-c90f3f4fe463-image.png] totally broken UI [image: 1767881852362-7ff52851-90b6-4845-90cd-f5190feabcbc-image.png] in DISK tab of the VM : [image: 1767881880851-62f582ab-afa7-4c29-bbd6-e83b1a73fab5-image.png] and it is really an ISO SR ! [image: 1767881925549-66fb75a7-f783-4809-ace9-e83e20722ebd-image.png] should this not be prevented ?