I suggest you ...

XCP: Allow storage Xenmotion to be used for backups (if up, source stays up, but leave target down)

Currently, storage Xenmotion allows either a shut-down VM and its storage to be copied to a new location or live storage Xenmotion takes a running VM + storage and relocates it to a new server/pool/storage location and runs it there and stops the source. Why not also allow the source VM to continue running or the shut down VM to stay shut down and instead of migrating, allow a total copy operation and leave the target VM/storage shut down so as to create a perfect backup snapshot? For disaster recovery or keeping a perfect clone handy of a VM+storage, this would be ideal and involve very little code change to what already exists to accomplish.

38 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    I agree to the terms of service
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Tobias KreidlTobias Kreidl shared this idea  ·   ·  Admin →

    5 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      Submitting...
      • Tobias KreidlTobias Kreidl commented  · 

        Has this not been considered yet for a future enhancement? It seems to have garnered quite a bit of interest (and votes).

      • Tobias KreidlTobias Kreidl commented  · 

        A. Cooper of Citrix reports on the Citrix forum this trick for getting a (soon to be) shut-down VM to storage Xenmotion: "If you start the migration at the same time as issuing `reboot` in the guest, it will shut down and stay shut down until the migration is complete. Migrating a shut down VM is safe, and does even work when migrating a VM between Intel and AMD cpus". This has to be done via the CLI and requires the "force" option. So, the framework is pretty much already provided for most of the means of creating an off-to-off move, though not with the source already off to begin with. We therefore have on-to-on (shutting down the initial instance when done) and on-to-off (kludged, with the initial instance off at the end), and are missing primarily the means to perform an on-to-off (leaving the source on and the target off), as well as a off-to-on (not requiring to first force the VM to run to pull it off and resulting in a running VM target) migration, as well as a pure off-to-off migration (the VM stays down at all times both on the source and target).

      • Tobias KreidlTobias Kreidl commented  · 

        Have recently tried migrating a shut-down VM this way and it appears to not work at all, and apparently requires the VM to be running to initiate the request. Why on earth, why? There is a "--live" (migrate without shutting the VM down) option in the CLI, so why would one not want to be able to migrate a shut-down VM and either bring the copied version up live on the new destination or leave it down, as well, in preparation for bringing up at a desired time? All these seem like little flags that can trigger what state to leave the VM in for both source and target VMs. Please consider broadening the scope of this extremely useful and powerful feature to offer a little more flexibility.

      • Tobias KreidlTobias Kreidl commented  · 

        Lars, your point about a migration failing is very well taken, especially with really large VDIs, this can sometimes take hours (and, yes, do sometimes fail). Also, if you want to leave your development VM on your QA server yet want to run it elsewhere without losing the original location, you really do not want to delete your original copy.

      • LarsLars commented  · 

        Absolutely agree. I've needed this feature many times. In the event of a live migration failing (this happens) being able to move a shut down guest to new storage/server/pool would be worth gold.

      Feedback and Knowledge Base