@julienXOvates Thanks for the quick reply, that’s very helpful!

I previously opened a forum topic about xe sr-create ignoring the name-description parameter, but the last comment/question there never received a response. This issue is specifically about another parameter that also appears to be ignored during SR creation: other-config:auto-scan=true.

Forum thread:
https://xcp-ng.org/forum/topic/12213/xapi-sr-create-ignores-name-description-parameter

When creating an SR with:

xe sr-create name-label="NFS-SR-01" name-description="NFS storage repository for VM disks" type=nfs content-type=user shared=true device-config:server=192.168.1.50 device-config:serverpath=/export/xe-storage other-config:auto-scan=true
b3c2a7d1-6f2e-4a91-9d3f-1a2c9d8e7f10


xe sr-list uuid=b3c2a7d1-6f2e-4a91-9d3f-1a2c9d8e7f10 
uuid ( RO)                : b3c2a7d1-6f2e-4a91-9d3f-1a2c9d8e7f10  
          name-label ( RW): NFS-SR-01  
                      ...
         other-config (MRW):
                      ...

the SR is created successfully, but the other-config:auto-scan=true value is not present afterwards.

Expected behavior:

• other-config:auto-scan=true should be persisted during sr-create
• or the command should explicitly reject unsupported parameters instead of silently ignoring them

Actual behavior:

• parameter appears to be silently ignored during creation

Environment
XCP-ng 8.3

@julienXOvates Thanks for the quick reply, that’s very helpful!

Hello,

I have a few questions regarding the ESXi → XCP-ng migration process and how Xen Orchestra handles it internally.

1. When VDDK is available and configured, how does the migration process work exactly?
2. Is the data transfer happening directly between the ESXi host and the XCP-ng host, or is the traffic proxied through Xen Orchestra as well?
3. I understand that migration can also work without VDDK. In that case, what method is used internally?
4. If VDDK is installed/configured in Xen Orchestra, is it possible to manually choose which migration method to use? I’m asking mainly for testing and benchmarking purposes. Or does XO automatically decide which method will be used?

Thanks in advance for any clarification.

@psafont Thank you for the quick response.

I also found a similar issue: the other-config:auto-scan=true parameter is not being applied during xe sr-create either. As with the name-description parameter, the workaround is to add it separately afterwards using xe sr-param-add.

Hello,

I’m not entirely sure whether this is a bug or expected behavior, so I’d like to ask for clarification here.

When creating an SR using xe sr-create with the name-description parameter, the command succeeds but the value is not persisted.

After creation, xe sr-list shows an empty name-description field. However, the value can be set correctly afterwards using xe sr-param-set.

Steps to reproduce:

xe sr-create name-label="NFS-SR-01" name-description="NFS storage repository for VM disks" type=nfs content-type=user shared=true device-config:server=192.168.1.50 device-config:serverpath=/export/xe-storage other-config:auto-scan=true
b3c2a7d1-6f2e-4a91-9d3f-1a2c9d8e7f10


xe sr-list uuid=b3c2a7d1-6f2e-4a91-9d3f-1a2c9d8e7f10 
uuid ( RO)                : b3c2a7d1-6f2e-4a91-9d3f-1a2c9d8e7f10  
          name-label ( RW): NFS-SR-01  
    name-description ( RW):  
                host ( RO): <shared>  
                type ( RO): nfs  
        content-type ( RO): user

Result:
name-description is empty.

Workaround:

xe sr-param-set uuid=<SR_UUID> name-description="test description"

Expected behavior:
The name-description value should be saved during sr-create.

Actual behavior:
The parameter is ignored without error.

Environment:
XCP-ng 8.3