Best posts made by olivier

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.

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)

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.

That's pretty much a good illustration.

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

So it means none of your host is currently doing "long" async tasks (like exporting or importing a VM)

Don't know.

But we are doing this in the code:

    if auto_poweron
      yield xapi.call 'VM.add_to_other_config', ref, 'auto_poweron', 'true'
      yield xapi.setPoolProperties({autoPowerOn: true})
    else
      yield xapi.call 'VM.remove_from_other_config', ref, 'auto_poweron'

So in theory, this should work.

@BRRABill autoboot issue fixed: https://github.com/vatesfr/xo-web/issues/879

Will be released in 4.16. Thanks for the report!

@Dashrender said in BRRABill's Field Report With XenServer:

@BRRABill said in BRRABill's Field Report With XenServer:

Question:

I migrated my VM from one XS to another. When the new VM came up, it ran a check disk, and then the networking was off.

If this is an export/import, why should any of that happened?

Well the disk was copied while it was running, so when you boot the disk on the new host, that system sees it's boot as if it crashed/shutdown improperly. As for the networking, I'm guess it's because the system is set to boot up while the original is still running. Disabling the network prevents the same server on two devices at once. It's not a real V-Motion solution as you used it.

I like when someone answer better on XO than I would!

That's indeed 100% correct:

• you probably made a copy (not a migrate because it seems you had to boot it)
• make a copy of a running VM relies on a snapshot
• booting an exact copy with the same IP setting explains why the network didn't came up (OS tried to start it but seen a conflict)

@BRRABill using a guest agent will be faster than a "copy" on hypervisor level (for the record, it uses compression and read the whole disk!)

Remember than a "copy" is a high level feature provided by XO, using streaming export from one server to VM import on the other side. With GZIP compression on XenServer. You bet it's slower than working on guest level!

If you want to compare backup speed, using continuous delta backup could be interesting: after the initial backup (which is not compressed), XO will only export delta (the diff written between the new backup and the previous one). And forever, because we (XO) will merge block of the oldest delta in the full (initial) backup. So no more full export after the first one.

So it's more comparable to your sector-level backup program (it uses the diff of the VHD format). The main difference is you don't need to install any program in your VM to have it working

Also a major difference between a backup tool on the guest: XO won't restore inside the VM. It will create a new VM (with the full file) then apply diff (if necessary).

The downside is "restore" time is higher. On the other hand, you could have lost your whole XenServer and having a brand new server, XO restore will still work.

To be able to rollback quickly, there is a solution, called snapshots.

In general, in IT operations, we use both:

• snapshots are very handy when you want to make a modification and rollback if anything goes wrong. It's also cool to schedule them every night in case
• but snapshots ARE NOT BACKUP. That's why cont. delta is perfect here: fast to create and your are protected, even in a catastrophic situation. If you lost your VDI chain/XenServer/whatever, a snapshot won't help at all.

But combining them is great. Restoration time of a catastrophic failure is not often a concern.

We are already using XAPI VDI export for our backup

@wrx7m said in Why is VMWare considered so often:

@coliver Veeam - It is awesome

Without being too off topic, could you list the top 5 things you like the most about VEEAM? This could give me ideas for XO

@scottalanmiller There is an issue while installing XO from the source, due to a breaking change in a dependency.

Fixed in next-release.

Guys, it's not even beta ready

Could you wait a bit? Issues like non-existing page and broken filters are perfectly normal at this stage. Also a lot of WIP

Also the home view will have a switch to VM/host/pool view

edit: let's say Friday it will be more complete

@travisdh1 I have no problem with that Just reporting some issues will be a bit useless before with finished some basic things!

@aaronstuder We had checked multiples interfaces yes.

And yes, the new one will be also responsive (it's mainly already the case in the current state of 5.0)

Hi there!

Let me recap the thing and put it in perspective.

The couple XenServer/XenCenter is targeting mainly Windows admins (thus the Windows client, the SP1 and so forth patching etc). You know, things that seems a bit strange inside the Linux world. It was really something wanted from Citrix to not "scare" their Windows public (have you ever seen the word "Linux" somewhere on XenServer/XenCenter?).

In this fabulous Windows world, you have to reboot very often for a lot of reasons.

Now, let's get to the point: XenServer updates are a kind of ugly tarball containing RPM packages (+ scripts) which are extracted on the host. In the patch metadata, there is a "recommendation" field, which gives you what to do after applying a patch. Roughly:

• if it's a lib or updated scripts: no reboot needed at all
• if it's kernel or hypervisor related: it will be used only after a reboot

But in all cases, there is no problem to install all patches at once, and do a reboot at the end. The missing info in XO is to display the recommandation field, which is now the case in the 5.0 interface.

So why on earth XenCenter will reboot your host 15 times? Even sometimes without asking you? I think that's really a bad behavior. It's up to you to decide.

Okay guys: we'll release Friday. For XOA users, they could access it via adding /v5 at the end of the current URLs (the "old" will be accessible by default). For sources users, it will be necessary to switch from stable to a specific branch (v5 probably).

This way, we could have feedback and not break stuff. Also people could compare and push feedback before we remove the "old" 4.x branch.