On the "Mode" column select DHCP or Static according to your preference.

@markhewitt1978 Hi, thank you for your feedbacks!

We are aware that this limitation bothers a lot of users and we have plan to address that in the next major version of XO.

XO 5 was already a major improvement over its predecessor because it allows viewing and handling a much bigger infra.

XO 6 will go further in this direction by introducing a tree view and the possibility to edit and handle many objects at the same time.

@harajukakei are you sure about the network too? It's a pool wide network?

Have you checked our guide to install Windows drivers? Check https://xcp-ng.org/docs/guests.html#windows

If you still have issues, with your current XOA account in trial, you can open support tickets already so we can take a look remotely (https://support.vates.fr)

Feature request oped

https://github.com/vatesfr/xen-orchestra/issues/5391

brezlord created this issue in vatesfr/xen-orchestra open Set pool wide Xen Motion Network #5391

@danp said in XO created snapshots are too visible:

I seem to recall this issue coming up previously. I think non-XO snapshots are flagged as templates to that they aren't included in the VM list.

Yes, I just found it here, https://xcp-ng.org/forum/topic/2718/xcp-ng-center-20-03-00-released/ , in the discussion between you, @hvilches , and @olivierlambert

It looks like it's not just XCP-ng Center / XenCenter that create snapshots with the is-a-template parameter set true. The xe CLI does as well when creating a snapshot with the xe vm-snapshot command and some xe commands like xe vm-list show the snapshots with is-a-template set false but not the ones with is-a-template set true. xe snapshot-list shows both types but allows you to select just one or the other with is-a-template=true (or false). xe template-list doesn't seem to allow showing the snapshots by trying to select using is-a-snapshot=true though the parameter is accepted and not flagged as an error.

Odd behavior all around. I only noticed it because I have scripts that parse through the vm-list output and end up catching XO snapshots but not others in the process.

I was originally thinking this might be a bug in XO but maybe it's actually a problem in the xe vm-list command or XAPI in general, i.e. a list of VMs shouldn't list snapshots the way it already doesn't list templates.

@akurzawa s3 backups/delta backups are not working great for big vms
but I never had this problem! check the bucket and directory

@moradin
Hello I also have this issue. Image 1 shows you the VM I want to migrate from server 1.
Image 2 shows you a VM on server 2 were I want to migrate to.

They have the same setting but it doesn't work.

I'm getting this errors on big vms:

{ "data": { "mode": "full", "reportWhen": "failure" }, "id": "1605563266089", "jobId": "abfed8aa-b445-4c94-be5c-b6ed723792b8", "jobName": "amazonteste", "message": "backup", "scheduleId": "44840d13-2302-45ae-9460-53ed451183ed", "start": 1605563266089, "status": "failure", "infos": [ { "data": { "vms": [ "68b2bf30-8693-8419-20ab-18162d4042aa", "fbea839a-72ac-ca3d-51e5-d4248e363d72", "b24d8810-b7f5-5576-af97-6a6d5f9a8730" ] }, "message": "vms" } ], "tasks": [ { "data": { "type": "VM", "id": "68b2bf30-8693-8419-20ab-18162d4042aa" }, "id": "1605563266118:0", "message": "Starting backup of TEST. (abfed8aa-b445-4c94-be5c-b6ed723792b8)", "start": 1605563266118, "status": "failure", "tasks": [ { "id": "1605563266136", "message": "snapshot", "start": 1605563266136, "status": "success", "end": 1605563271882, "result": "a700da10-a281-a124-8283-970aa7675d39" }, { "id": "1605563271885", "message": "add metadata to snapshot", "start": 1605563271885, "status": "success", "end": 1605563271899 }, { "id": "1605563272085", "message": "waiting for uptodate snapshot record", "start": 1605563272085, "status": "success", "end": 1605563272287 }, { "id": "1605563272340", "message": "start VM export", "start": 1605563272340, "status": "success", "end": 1605563272362 }, { "data": { "id": "7847ac06-d46f-476a-84c1-608f9302cb67", "type": "remote" }, "id": "1605563272372", "message": "export", "start": 1605563272372, "status": "failure", "tasks": [ { "id": "1605563273029", "message": "transfer", "start": 1605563273029, "status": "failure", "end": 1605563715136, "result": { "message": "write EPIPE", "errno": "EPIPE", "code": "NetworkingError", "syscall": "write", "region": "eu-central-1", "hostname": "s3.eu-central-1.amazonaws.com", "retryable": true, "time": "2020-11-16T21:55:08.319Z", "name": "NetworkingError", "stack": "Error: write EPIPE\n at WriteWrap.onWriteComplete [as oncomplete] (internal/stream_base_commons.js:92:16)" } } ], "end": 1605563715348, "result": { "message": "write EPIPE", "errno": "EPIPE", "code": "NetworkingError", "syscall": "write", "region": "eu-central-1", "hostname": "s3.eu-central-1.amazonaws.com", "retryable": true, "time": "2020-11-16T21:55:08.319Z", "name": "NetworkingError", "stack": "Error: write EPIPE\n at WriteWrap.onWriteComplete [as oncomplete] (internal/stream_base_commons.js:92:16)" } }, { "id": "1605563717917", "message": "set snapshot.other_config[xo:backup:exported]", "start": 1605563717917, "status": "success", "end": 1605563721061 } ], "end": 1605564045507 }, { "data": { "type": "VM", "id": "fbea839a-72ac-ca3d-51e5-d4248e363d72" }, "id": "1605564045510", "message": "Starting backup of DESKTOPGREEN. (abfed8aa-b445-4c94-be5c-b6ed723792b8)", "start": 1605564045510, "status": "failure", "tasks": [ { "id": "1605564045533", "message": "snapshot", "start": 1605564045533, "status": "success", "end": 1605564047224, "result": "3e5fb1b5-c93e-f242-95a2-90757b38f727" }, { "id": "1605564047229", "message": "add metadata to snapshot", "start": 1605564047229, "status": "success", "end": 1605564047240 }, { "id": "1605564047429", "message": "waiting for uptodate snapshot record", "start": 1605564047429, "status": "success", "end": 1605564047631 }, { "id": "1605564047634", "message": "start VM export", "start": 1605564047634, "status": "success", "end": 1605564047652 }, { "data": { "id": "7847ac06-d46f-476a-84c1-608f9302cb67", "type": "remote" }, "id": "1605564047657", "message": "export", "start": 1605564047657, "status": "failure", "tasks": [ { "id": "1605564048778", "message": "transfer", "start": 1605564048778, "status": "failure", "end": 1605564534530, "result": { "message": "write EPIPE", "errno": "EPIPE", "code": "NetworkingError", "syscall": "write", "region": "eu-central-1", "hostname": "s3.eu-central-1.amazonaws.com", "retryable": true, "time": "2020-11-16T22:08:35.991Z", "name": "NetworkingError", "stack": "Error: write EPIPE\n at WriteWrap.onWriteComplete [as oncomplete] (internal/stream_base_commons.js:92:16)" } } ], "end": 1605564534693, "result": { "message": "write EPIPE", "errno": "EPIPE", "code": "NetworkingError", "syscall": "write", "region": "eu-central-1", "hostname": "s3.eu-central-1.amazonaws.com", "retryable": true, "time": "2020-11-16T22:08:35.991Z", "name": "NetworkingError", "stack": "Error: write EPIPE\n at WriteWrap.onWriteComplete [as oncomplete] (internal/stream_base_commons.js:92:16)" } }, { "id": "1605564535540", "message": "set snapshot.other_config[xo:backup:exported]", "start": 1605564535540, "status": "success", "end": 1605564538346 } ], "end": 1605571759789 }, { "data": { "type": "VM", "id": "b24d8810-b7f5-5576-af97-6a6d5f9a8730" }, "id": "1605571759883", "message": "Starting backup of grayLog. (abfed8aa-b445-4c94-be5c-b6ed723792b8)", "start": 1605571759883, "status": "failure", "tasks": [ { "id": "1605571759912", "message": "snapshot", "start": 1605571759912, "status": "success", "end": 1605571773047, "result": "600bf528-8c1d-5035-1876-615e1dd89fea" }, { "id": "1605571773051", "message": "add metadata to snapshot", "start": 1605571773051, "status": "success", "end": 1605571773081 }, { "id": "1605571773391", "message": "waiting for uptodate snapshot record", "start": 1605571773391, "status": "success", "end": 1605571773601 }, { "id": "1605571773603", "message": "start VM export", "start": 1605571773603, "status": "success", "end": 1605571773687 }, { "data": { "id": "7847ac06-d46f-476a-84c1-608f9302cb67", "type": "remote" }, "id": "1605571773719", "message": "export", "start": 1605571773719, "status": "failure", "tasks": [ { "id": "1605571774218", "message": "transfer", "start": 1605571774218, "status": "failure", "end": 1605572239807, "result": { "message": "write EPIPE", "errno": "EPIPE", "code": "NetworkingError", "syscall": "write", "region": "eu-central-1", "hostname": "s3.eu-central-1.amazonaws.com", "retryable": true, "time": "2020-11-17T00:17:01.143Z", "name": "NetworkingError", "stack": "Error: write EPIPE\n at WriteWrap.onWriteComplete [as oncomplete] (internal/stream_base_commons.js:92:16)" } } ], "end": 1605572239942, "result": { "message": "write EPIPE", "errno": "EPIPE", "code": "NetworkingError", "syscall": "write", "region": "eu-central-1", "hostname": "s3.eu-central-1.amazonaws.com", "retryable": true, "time": "2020-11-17T00:17:01.143Z", "name": "NetworkingError", "stack": "Error: write EPIPE\n at WriteWrap.onWriteComplete [as oncomplete] (internal/stream_base_commons.js:92:16)" } }, { "id": "1605572242195", "message": "set snapshot.other_config[xo:backup:exported]", "start": 1605572242195, "status": "success", "end": 1605572246834 } ], "end": 1605572705448 } ], "end": 1605572705499 }

also delta backup have the same problem

@naeemarsalan Good catch, It will be added to the cloudinit script creating the master and the nodes.

This will save one reboot to everyone.

It's a little different, but if in Xen Orchestra you go:
Home => Hosts => <host> => Network
there I can see my storage IP addresses comparable to that "IP Address Configuration" part.

Except that here, all the networks are listed in the same list.
Can you see if that's what you are looking for?

Is there a way to access your OVA so we can try to reproduce?

Existing HA level is at VM level. It means, if the VM is down (or the host on the VM is running is down), it will be booted on a working host in that pool.

For hyperconvergence, it's far from being a miracle solution. It costs a lot of thinking, planning and maintenance (and careful usage of it).

Like HA in the end.

So before asking for advanced features, it's good to think about what you really need.

He also said there's a fix coming for the next release.

@olivierlambert Thanks, I tried running fstrim but it returned "the discard operation is not supported" on this NFS SR mount. I also tried running on SSD mounts which do support TRIM and they all returned the same message about "discard...not supported."

The VM OS (CentOS 7.8) does support TRIM in kernel so not sure if xcp-ng or xenserver is the reason why the VM can't issue fstrim on the NFS SR mount or the SSD SR mounts.

When you migrate a VDI to another SR, its UUID is changed. So it's like a "new VDI".

However, there's an issue opened a while ago: https://github.com/vatesfr/xen-orchestra/issues/2896

We did not have a priority on this because not a lot of people asked for it.

I think it could be a good optional feature in a job.

snimmerjahn created this issue in vatesfr/xen-orchestra open [Delta Backup] Avoid full export after VDI migrate #2896

It's in our documentation, please read https://xen-orchestra.com/docs/configuration.html#https

@olivierlambert no need to extend trial , thank you though. I will put out the communication to team and see if they want to do before the beginning of the year.

So far, I noticed this problem for three VMs. Each time I am trying to perform a backup with zstd compression through XO, the backup is marked as successful, but output XVA file is damaged (incomplete). The backup works fine for all other VMs, and I cannot pinpoint what is special about these faulty VMs.