mdm

I'm trying to understand the intended design of the XCP-ng logging configuration.

XCP-ng uses rsyslog to trigger /etc/cron.daily/logrotate when certain log files reach 100 MiB, so they don't have to wait for the next scheduled daily logrotate run.

Looking at /etc/rsyslog.d/xenserver.conf, there are outchannel definitions with a 100 MiB limit for several log files (kern.log, daemon.log, user.log, secure, maillog, cron, xensource.log, etc.).

However, /var/log/messages does not appear to have such an outchannel.

I understand that /var/log/messages is also part of the traditional CentOS/RHEL syslog configuration, rather than being an XCP-ng-specific log. So I'm wondering where the responsibility for limiting its size is supposed to lie.

Is the expectation that the underlying CentOS logging configuration and normal daily logrotate are sufficient for /var/log/messages, while XCP-ng adds the 100 MiB rsyslog trigger only for its own/specific log files?

If /var/log/messages can receive a sufficiently high volume of messages, could it theoretically grow large enough to fill the log partition before the next daily logrotate run?

If so, would it make sense for XCP-ng to add the same 100 MiB rsyslog trigger for /var/log/messages, or is there a specific reason why this would not be appropriate?

@psafont Thanks for the quick response and clarification. I appreciate you opening a work item for this. Looking forward to seeing this improvement in a future release.

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