I just saw an email about unsigned long and max memory fly by along with a comment like "32-bit will never have more than 'X' Gb" ... This raises an obvious question: is libvirt explictly not 32/64 clean? On Solaris we build everything 32-bit by default unless there is a reason for it to be 64-bit. If a 32-bit libvirt can't handle a 64-bit kernel, then we have a problem. IMO an API should *always* use explicitly-sized integers when they contain range or size values (or use size_t etc.). Not doing so is both dangerous and confusing... (Xen does indeed have this problem, so we run all their tools with native word size. Currently we always use a 32-bit libvirt for 'virt-install', and it does seem to work fine. It would be a pity for this to change). cheers john -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list