Okay so it could be 2 snapshots. This shouldn't be by default, be an interesting option indeed.

Yes, totally. Sometimes it's not possible, so you got CPU masking as an alternative: http://support.citrix.com/article/CTX127059

That's pretty much a good illustration.

Roughly, migration without storage is like this in XenServer:

• a snapshot is created on the origin host
• every new write is now streamed on both hosts (origin and destination)
• disks are copied

When this is done, it's a classical live migration:

• RAM is transfered
• VM is suspended a fraction of time on the origin host
• last RAM transactions are copie on the destination host
• VM is "resumed" (un-suspended) on destination

So your VM will continue its life without knowledge of the new hardware. Let's imagine you have a recent CPU on the origin host, with the "FOOBAR" instruction. Let's also imagine this "FOOBAR" instruction is not on the destination host CPU.

Your VM booted with this "FOOBAR" capable CPU, so for it, that's OK to call it. Imagine what happened when the call happen on the destination host (kernel is crash \o/).

More fun? Migrate a VM from two CPUs vendors (Intel/AMD), while running a Java program inside the VM. If you love fireworks, worth the shot.

So it's basically the possibility to take a snapshot of a snapshot?

It's always a trade off. At least, it will be a quiesce snapshot if your Windows VM support it.

But ideally, to avoid any risk, shutdown THEN copy is the safest solution.

Depends of risk level (and downtime!) you can accept (eg live migration is still possible, but you could possibly reboot at destination if CPU instructions are not correct)

At least what we already got in XO. What do you mean by "split"?

If it's up, we are taking a snapshot AND copy it. So it doesn't matter.

Not yet, but that's a good idea yes.

Our "special" VM copy is doing this:

Check the "Copy" button in the VM view, select a destination SR, and you are done.

edit: original blog post: https://xen-orchestra.com/blog/vm-streaming-export-in-xenserver/

@DustinB3403 I can't tell which IP is on which interface.

I will only display one address on the General tab (imagine if we got 10 addresses...). Keep in mind the goal is to avoid brain overwhelming with too many tings displayed at the same time.

All IP addresses will be displayed in the Network tab.

In the Network tab I presume. Because you can have multiple interfaces.

In the picture? This is a VM view (but without anything around, which is missing yet, ie the top menu, etc)

XO will try to force migrate, but from a recent to an older CPU, the result is half of the time a kernel panic (older to recent CPU is less problematic, you'll keep using existing instruction from the old CPU without exploding in flight, contrary to trying a recent CPU instruction which doesn't exist on an older CPU)

Hi everyone,

Just created a topic there for new UI suggestions: https://xen-orchestra.com/forum/topic/186/the-new-5-x-interface

Feel free to make suggestions or to give ideas of nice layouts you already seen elsewhere. Or things you loved on other hypervisors UIs.

If it don't, check the xo-server output. This won't lie and tell us what's going on.

Yes, as @Danp said, there is always a pool: a "single" host is by default in a pool with no name label.

XenCenter choose to hide this, not us.

@BRRABill

1. Yup
2. Yup

But you need to define a default SR on any pool you got. Eg: xe pool-param-set uuid=<pool-uuid> default-SR=<sr-uuid> (with the SR UUID of the local storage if you don't have a shared storage).

You can also do it with XenCenter or XO (see https://xen-orchestra.com/blog/set-the-xenserver-default-sr/ )

A live migration won't interrupt the VM, so even with XO on it: doesn't matter.

Figure 1: me actually lurking in this thread