Short version:
Check that you have /etc/udev/rules.d/xen-backend.rules. The file may or may not be prefixed by a number.
If not, check whether you have /etc/udev/xen-backend.rules and create a symlink from that to /etc/udev/rules.d/xen-backend.rules.
Long version:
I've seen this with a Gentoo 3.3 dom0, not CentOS. But I suspect the fix will be the same or similar.
The Xen build scripts call a command udevinfo -V to determine the version of udev installed on the machine. The udevinfo utility was depreciated a while ago in favour of udevadm. In more recent releases of udev the old utility has been removed altogether.
The build scripts use the version of udev acquired as described to determine what installations steps need to be undertaken. If it can't find/match the udev version then it won't installed the required udev rule. By not having udevinfo present, this is what's occurring.
Now it's probably given that you don't want to downgrade udev. So that leaves two solutions.
You can either check whether your package distributor has fixed the issue. For instance it is fixed in Xen 4.4 on Gentoo in accordance with this bug.
Alternatively, you can work around it temporarily, by fooling it that udevinfo is still present and behaving in the way that it expects. We can do this by scripting/proxying to the new udevadm command:
# echo -e '#!/bin/bash\n/sbin/udevadm info $1' > /usr/bin/udevinfo
# chmod +x /usr/bin/udevinfo
*** Install Xen ***
# rm /usr/bin/udevinfo
This will get it working again. But you will still need to fix the issue in the long run.
Best Answer
The module that is missing is pam_pwquality.so, fixed by
sudo yum install libpwquality