Description of problem: Version-Release number of selected component (if applicable): Name : virt-manager Arch : x86_64 Version: 0.2.2 Release: 1.fc6 Name : xen Arch : x86_64 Version: 3.0.2 Release: 36 How reproducible: 100% Steps to Reproduce: 1. start virt-manager 2. create new vm, name=xptest method=fully virtualised dvd location=/media/xpdisk (not using .iso file) disk=lvm partition /dev/mapper/vg0-lv2_xphome (also tried simple file) guest memory =500Mb host memory=2GB vcpu count=1 host cpu count=2 (this is a single CPU Xeon 5110) confirm all details on summary screen, click finish Actual results: a dialog box is raised and closed so quickly I can't see it's contents if using a simple disk file, then it is created, otherwise notjhing happens tried running v-rt-manager from console to catch any stdout/stderr messages, but none given, checked dmesg and saw a coiple of selinux denied messages, # dmesg SELinux: initialized (dev hdb, type iso9660), uses genfs_contexts audit(1159360699.813:13): avc: denied { search } for pid=3536 comm="python" name="media" dev=dm-0 ino=360449 scontext=system_u:system_r:xend_t:s0 tcontext=system_u:object_r:mnt_t:s0 tclass=dir audit(1159360699.813:14): avc: denied { getattr } for pid=3536 comm="python" name="/" dev=hdb ino=1536 scontext=system_u:system_r:xend_t:s0 tcontext=system_u:object_r:iso9660_t:s0 tclass=dir re-tried with selinux permissive mode instead of enforcing mode, no better "xm dmesg" doesn't seem to show anything erelated to creating a new VM "xm list" only shows dom-0 Expected results: new VM created :-)
Created attachment 137217 [details] /var/log/xen/xend.log
The problem is that we mistakenly passed the CDROM mount point, rather than device node to Xen. This is a dup of bz 206965 so closing this ticket. *** This bug has been marked as a duplicate of 206965 ***
I saw the reference to the mountpoint in the log file so created an .iso file from the CD using dd, when I specified the iso file instead of the optical device, virt-manager seemed to gop a stage further, but xen rebooted the host machine :-( If I can duplicate I'll log a new bug ...
If its got as far as starting the VM, then this is likely a bug in the HVM part of xen, so file it against 'xen' component. For HVM guests its also useful to include 'xm dmesg' output as well as regular qemu-dm & xen & xen-debug logs from /var/log/xen/