Description of problem: See thread here -- https://www.redhat.com/archives/et-mgmt-tools/2009-March/msg00088.html -- Windows installs in F10 eject the install media almost immediately after starting the install (~5 seconds in) and can't get at the CD ROM from virt-manager or virtinst. This problem is not present in rawhide, so the fix needs to be backported to enable F10 to work. All details are in the thread.
Could you try the versions in F10 updates-testing?
This was reproduced in rawhide Friday (soon to be F11 beta), do you still need a check against F10 updates-testing? It seems that if it happens in F10 and rawhide, F10-testing would be the same? If you still need that, just let me know.
Hmm, you said it's fixed in rawhide? F10 updates-testing has a fairly recent version, so if it's fixed in rawhide it might well be fixed in F10 updates-testing Since I don't think we know what changed in virt-manager to fix it, the only way to check is by testing
Nope, it was broken in rawhide. That's what I meant by reproduced.
Okay, I was going by your original "this problem is not present in rawhide" comment. So, this is qemu-0.10-0.9.kvm20090310git.fc11, libvirt-0.6.1-5.fc11 and python-virtinst-0.400.3-1 Please attach /var/log/libvirt/qemu/$(domain).log, ~/.virt-manager.log and anything else useful you can think of. It's a little hard to tell at this point whether it's a random qemu bug or whether virtinst/libvirt is somehow doing something wrong here.
Created attachment 338347 [details] log from ~/.virtmanager on rawhide
Created attachment 338348 [details] /var/log/libvirt/qemu/win2008_bugzilla.log
The above logs are from rawhide latest as of 11:00 AM EST, 4/6: libvirt-0.6.2-1.fc11.i586 python-virtinst-0.400.3-4.fc11.noarch qemu-0.10-6.fc11.i586 And just to confirm, this happens with the ISO on the filesystem (/opt/images/win2008.iso), but does not happen when given the actual CDROM. For purposes of Cobbler/ovirt/misc-automated-stuff, we need to use the ISO, not the CDROM. (Running as root, SELinux is disabled, so none of that should be in the way)
Okay, no obvious cause in the logs - it looks to me like this should be reproducible with qemu on its own
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
Could you try with qemu-0.10.5-2.fc11? https://admin.fedoraproject.org/updates/qemu-0.10.5-2.fc11 It has a fix to prevent qemu from ejecting a locked cdrom, maybe that'll help
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle. Changing version to '11'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Three months, no update. Closing, hopefully it's fixed now anyway