XCP-ng
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Groups
    • Register
    • Login

    CBR start operation is blocked

    Scheduled Pinned Locked Moved Management
    3 Posts 3 Posters 41 Views 3 Watching
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • M Offline
      Milenko
      last edited by

      Hi guys.
      I am currently testing Continuous Replication as our way, to migrate our vms from one pool, to another. So i set up a test vm and a replication job on the same pool (different sr), since i dont have the new pool yet. Everything worked fine, job is running and creating the replicated vm. But when i want to start the vm, i will get the warning "Forbidden operation Start operation for this vm is blocked." I could klick "force start" but i am afraid, the universe will dissolve. So what is the best practice for my task? Do i have to recreate the vms and attach the cr disks, or is there a way to unblock the cr vm and use it as the new vm? I will have to migrate about 30 vms with 15TB so i obviously dont want to clone the cr vm to a new one. Or do i?

      Kind regards

      Milenko

      poddingueP P 2 Replies Last reply Reply Quote 0
      • poddingueP Offline
        poddingue Vates 🪐 @Milenko
        last edited by

        I think that blocked start is actually on purpose rather than something gone wrong: XO guards a continuous-replication target, so you can't accidentally boot the replica and have it drift from the source while the job keeps running.
        The documented way to bring one up is the failover process (https://docs.xen-orchestra.com/xo5/incremental_replication#failover-process), and for a real cutover, that's just starting the replica on the destination side; there's also a tip there about making a copy first if you want to start it without breaking the CR job on the source.
        So, for your pool-to-pool move, I don't think you'd need to recreate the VMs and reattach disks; the failover flow is meant for pretty much exactly this.

        I'd test the whole cycle on your one VM before committing the other 30.

        1 Reply Last reply Reply Quote 0
        • P Offline
          Pilow @Milenko
          last edited by Pilow

          @Milenko if this is a definitive migration pathway for you, you can force start the replica VM, no problem, you can even delete the replica snapshot.
          Just disable the job at source, it will create a new replica VM otherwise

          if it is just a test boot of the replica, fast clone it, and start the fast clone (beware of double ip addressing while doing so... source VM should be halted, or replica clone should be started without network)

          1 Reply Last reply Reply Quote 0

          Hello! It looks like you're interested in this conversation, but you don't have an account yet.

          Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.

          With your input, this post could be even better 💗

          Register Login
          • First post
            Last post