Subcategories

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

    428 Topics
    3k Posts
    M
    I am seeing this error on all VMs on a host. [image: 1766290197936-96981f62-9efe-4c25-ab6f-c65616089183-image.png] https://docs.xcp-ng.org/vms/#xsa-468-multiple-windows-pv-driver-vulnerabilities I have checked the Xen Tools and the latest version is installed. [image: 1766290358785-d712e614-47e9-4765-b665-b88322f5fbaa-image.png] https://www.xenserver.com/downloads [image: 1766290520784-e0effb7e-a93e-4d91-8f5e-0494ea3323ee-image.png]
  • ACLs, Self-service, Cloud-init, Load balancing...

    97 Topics
    818 Posts
    olivierlambertO
    October release fixed it
  • All XO backup features: full and incremental, replication, mirrors...

    441 Topics
    4k Posts
    P
    Dear all, I needed to do a complete new installation of xcp-ng 8.3 LTS. I have backups of all VMs incl. the pool metadata. The latest daily backup was done on 09th of December and now, if upgrade the fresh installed xcp-ng to v35 release, the metadata backup can't be restored. Either by XenOrchestra or with "xe pool-restore-metadata" the restore is possible, always same error: "failed: restore incompatible version". Any ideas what I'm doing wrong?
  • Everything related to Xen Orchestra's REST API

    75 Topics
    571 Posts
    F
    @MathieuRA Thank you, perfect Br,
  • Terraform, Packer or any tool to do IaC

    45 Topics
    427 Posts
    CyrilleC
    Terraform provider release v0.37.0 Enables the secure boot parameter for the VM resource Terraform provider release: https://github.com/vatesfr/terraform-provider-xenorchestra/releases/tag/v0.37.0
  • XOA Report

    3
    0 Votes
    3 Posts
    628 Views
    A
    @olivierlambert many thanks for the very quick response, it is indeed XO from sources. I think the burst explanation makes sense. Also, thanks for you and your teams continued development and support with both XCP-NG and XO.
  • Backups failed after changing masters?

    6
    0 Votes
    6 Posts
    1k Views
    olivierlambertO
    Source: https://github.com/vatesfr/xen-orchestra/issues/5969 olivierlambert created this issue in vatesfr/xen-orchestra closed Save all associated host IPs to a pool and use them as fallback for XAPI connection #5969
  • Lots of Tasks: Xapi#getResource /rrd_updates (on **masterhost**) 0%

    19
    0 Votes
    19 Posts
    3k Views
    stormiS
    And the IRC channel is #xcp-ng on oftc.net if you prefer IRC.
  • Usage of job.run.Sequence

    6
    0 Votes
    6 Posts
    802 Views
    F
    Hi, thank you for your support. I was out of Office for two weeks and will test this soon. I will give you feedback. Regards, Torsten
  • Jobs

    Solved
    5
    0 Votes
    5 Posts
    918 Views
    D
    Thank you for your help this is the solution i was searching for, I appriciate this much.
  • Missing information in XOA 5.64 blog post

    4
    0 Votes
    4 Posts
    706 Views
    olivierlambertO
    What do you mean "how it works"? It's the same thing than before, just "isolated" from the rest, working in a... worker. And yes, the long run objective is the ability to run it as a service on the remote directly, reducing a lot the merge time (because latency is the worst enemy of merging).
  • Backup does not work if one host in the pool is offline

    12
    0 Votes
    12 Posts
    1k Views
    ForzaF
    @olivierlambert said in Backup does not work if one host in the pool is offline: When you connect to a working, machine, yes it does But XAPI connection isn't persistent: it means, when the pool is disconnected, XO has no recollection whatsoever on who was the "real" master the last time it was connected. The only info we store is the IP address you entered in Settings/server. I agree, functionally speaking, it can be limiting in your case. A viable option would be to save all existing hosts IPs in the XO database, as fallback if we can't connect to the IP you entered. This is not a very common case, that's why it wasn't done before Looks like a good suggestion. Thanks. In my case I migrated everything from the poolmaster to the second host, then changed the second host to pool master, waited an hour and then shut down the old pool master (now just a pool member). XOA was online during the entire process and I had forgotten to check the server list.
  • Overview of a logical allocation of thin provisioned SRs

    6
    2
    0 Votes
    6 Posts
    939 Views
    olivierlambertO
    That's because the effort to change this will be taken into account in XO 6 Alternatively, you can indeed contribute, this will be very welcome!
  • Delta backup fails for specific vm with VDI chain error

    79
    0 Votes
    79 Posts
    22k Views
    M
    Hi ! We are experiencing these kind of problems because we activated Continous Replication and frequency was way too low. Now I want to eliminate all those files in the chain, can I do it manually from XCP-NG Center or XOA ? Thanks !!! [image: 1635327169557-c2aa1fb3-2ed2-41cf-b242-e2a23e6832e4-image.png]
  • continuous replication job - no progress

    Solved
    21
    0 Votes
    21 Posts
    6k Views
    olivierlambertO
    Ping @julien-f and/or @fohdeesha
  • Netbox Debugging

    Solved
    9
    1
    0 Votes
    9 Posts
    2k Views
    jedimarcusJ
    @pdonias I did an update to Netbox 2.11.12 and it works now, so I don't need to tamper with my XOA.
  • XCP host rebooted: VM's wont start anymore :-(

    40
    0 Votes
    40 Posts
    10k Views
    olivierlambertO
    It can't be done by XO, because XO is using XAPI to make all calls (there's no XAPI command to rename a file on the SR, also XO isn't connected via SSH, so there's 0 change it was caused by XO). So it was done manually at some point (check your host bash history).
  • 0 Votes
    6 Posts
    2k Views
    pdoniasP
    Thanks @cookie-eater2000, we'll take a look.
  • Allowing replicated server to start

    4
    0 Votes
    4 Posts
    510 Views
    olivierlambertO
    There's no issue nor restriction to replicate a shutdown VM. CR will work as long as the destination VM never booted (otherwise destination blocks will be modified, so you understand now why we should block boot except if you really know what you do )
  • Error: footer1 !== footer2

    10
    0 Votes
    10 Posts
    2k Views
    M
    @julien-f said in Error: footer1 !== footer2: @markhewitt1978 In that case, please open a support ticket there and then, open a support tunnel for us to investigate Thanks. I shall run it one more time manually to make sure. And if it fails I’ll open a ticket Thanks.
  • Xen Orchestra CLI

    Solved
    7
    0 Votes
    7 Posts
    3k Views
    S
    @stormi Awesome! Thanks again for your help stormi.
  • Backup, CR and snapshots question

    2
    0 Votes
    2 Posts
    949 Views
    olivierlambertO
    Correct, no problem to do that No other limitation. Yes, space will be reclaimed thanks to coalesce after that.
  • Why XOA did not restore the backup to a vm, but a template

    6
    0 Votes
    6 Posts
    1k Views
    T
    @ninghe Are A and B identical servers? No shared storage? Does it work if you use normal snapshot mode?
  • Backup storage - what connects to the remote storage device?

    2
    0 Votes
    2 Posts
    513 Views
    olivierlambertO
    Hi, It doesn't' work that way. XCP-ng is not capable of pushing any data by itself, it has to be pulled. That's exactly why we manage to build XO Proxies to solve this kind of common "enterprise" issue, when you have remote sites
  • Backing up the backup

    5
    0 Votes
    5 Posts
    1k Views
    M
    Doing a bit more hunting it seems like if we could get Arcserve to use the nolock option then that would likely solve the problem, but there's nowhere to add any options and the Arcserve Proxy itself uses the Windows NFS client behind the scenes. Right now we've worked around the problem by creating a separate, read-only SMB share pointing to the same location and using that for Arcserve instead. Our only concern now is what could happen if XO starts a job while Arcserve is still doing its own backup. Edit: I did a bit more Googling after posting the above and came across this thread: https://www.truenas.com/community/threads/nfs-the-process-cannot-access-the-file-because-another-process-has-locked.12644/ ... which suggests that it's actually a long-standing TrueNAS bug. Buried within the comments is this suggestion: If you're having trouble with the NFS locking mechanism, and you would like to use the "NET USE" command, or the [WNetAddConnection] function to mount a NFS share without locking, there's an undocumented registry entry hidden in the NFSNP.DLL: "HKLM\Software\Microsoft\Client for NFS\CurrentVersion\Users\Default\Mount" REG_DWORD "Locking" If the value is "0x0" then locking will be disabled globally. If the value is "0x1" then locking will ben enabled globally. We'll test it and report back.