1. No reason come in my mind. Maybe guest/Windows reasons?
2. If any hardware change for the guest OS, maybe it's related?
3. NIC are different probably because they got a new MAC address (again guest OS behavior)

I said snapshots are used for exporting Running VMs. If your VM is halted, no need to create a snapshot.

You can create a basic backup schedule and de-activate the compression, then run the job manually. You'll have an export without compression.

@Dashrender Citrix always explain that pools should have homogeneous CPUs/hardware

@Dashrender For backup yes, not for VM copy.

@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)

We'll have indeed more sources coming (and better graphs) in the 5.x branch. There is a lot of sources available, so again, the thing will be to display main graph and allow extra stuff if needed.

XO is activating the compression by default for a VM copy. And because of GZIP and probably a not so fast CPU, the bottleneck is there.

Sadly, we had a choice to make, between faster copy but larger bandwidth usage and the opposite. Changing it is easy, but I have a bad feeling about this (a lot of people not agree with the new choice).

The best would be to have the choice, but it's tricky in term of UI.

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

Will be released in 4.16. Thanks for the report!

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.

AFAIK, XO would do both (activate the "autopower" on your VM but also on its pool).

If it's not the case anymore, maybe something is broken on our side. Let me check that.

Hmm no autopower_on activated. I imagine you already tick the checkbox on the XO GUI? Normally, this will add the right parameter in the pool. If not, I have to check this on my side too.

@BRRABill Yes It could be added, but XAPI tasks are such a mess. We can't be sure about them, but yes it's possible to fetch them and store them somewhere. But it will be only informative and not the "truth".

About auto power on: if you did it with XO, it's normally done in both pool and VM at the same time (see https://xen-orchestra.com/blog/auto-start-vm-on-xenserver-boot/ ).

To check your current pool status with autopower on: xe pool-param-get uuid=<POOL_UUID> param-name=other-config

@BRRABill Okay so the only difference with us is they keep ended tasks for a time (how much time?)

About the progress: XenCenter uses the pure XML-RPC way of calling XAPI, which is less prone to bugs, but very CPU intensive (I mean, VERY cpu intensive: decoding tons of XML is horrible)

Using JSON encapsulated in XML-RPC made a small difference for larger infrastructure, around 250 times faster than the shitty XML (for larger infrastructure). See https://xen-orchestra.com/blog/improving-xen-orchestra-performances/ That's the only way for us to have XO working on infrastructure with 1k VMs or more (the problem starts with 100 VMs)

But sadly, they made mistakes in JSON and it's only fixed in Dundee.

This is the XenServer task list. Is the task stays at "Success" when it's done? (eg with the migration?)

@BRRABill Can you provide a real world example with a XC screenshot?

"Tasks" are a XAPI object, telling you something happening on your host.

The progress value is broken in all current versions of XenServer (fixed in Dundee).

Making a VM copy is a complex task:

• we start to download chunks on the HTTP export handler of the origin host
• at the same time, we start to upload those chunks (on the fly) on the destination host

Each one of them had their respective tasks (export and import) but they don't "know" we are in fact "streaming" stuff between them (for them, it's more like a classical import or export).

Plus, XAPI is a pain to know when the transfer is finished (we had to use some hacks, because they don't use HTTP standard). Furthermore, we don't have the size of what we are exporting, so we can't "guess" the progress by ourselves.

It could fail on any side (fail export, fail import, for many reasons). So we catch anything we could.

But for now, there is no "XO" tasks, just multiple "XenServer tasks".

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

The task list just near the main menu.

You got tasks visible in the top menu (progress is broken due to a bug in XenServer).

Indeed there is a log in XO, but if you are using the sources, I can't tell where, depends on how you installed it.