I've tried this same test on a system running xen 3.0.2, and as I expected everything works fine. So, there must be something different about xen 3.0.1 that libvirt is not accounting for.
That's possible. If you still have that setup around, could you rerun virsh (as root ) under gdb and put a breakpoint in xenHypervisorInit and see what's happening in the first hypervisor call values of hc.op and cmd, and return value (hv_version). Then what's happen in the second call (is it failing too ?) in that same routine.
Sure, I can do this. I'll let you know what I find later on today.
Ok, I had a chance to run libvirt through the debugger as you asked. Here's what I got back: After the first ioctl: (gdb) ptype hc type = struct privcmd_hypercall { __u64 op; __u64 arg[5]; } (gdb) print hc.op $6 = 17 (gdb) print cmd $7 = 3166208 (gdb) print ret $8 = -1 Then, after the second ioctl: (gdb) ptype old_hc type = struct old_hypercall_struct { long unsigned int op; long unsigned int arg[5]; } (gdb) print old_hc.op $11 = 17 (gdb) print cmd $12 = 1593344 (gdb) print ret $13 = 196608 The second ioctl appears to succeed. One additional item of note is that I am running code that was compiled against xen 3.0.2, but is running on 3.0.1. This may be part of the problem. If there are any other quick tests you'd like me to run, just let me know. Pete