tags 652447 + moreinfo thanks On 17.12.2011 15:02, Marc Lehmann wrote: > Package: qemu-kvm > Version: 1.0+dfsg-1 > Severity: normal > > after upgrading from 0.15.1+dfsg-1 to 1.0+dfsg-1 in experimental, a large > number of vms > stopped working.
Note that 1.0 is in unstable already, so we don't have 0.15 anymore. > 2. netbsd4 and netbsd5 > > both of these boot, but cannot find the pcnet network card, nor other > network cards supported by both qemu-kvm and netbsd. both the generic as > wlel as the generic-noacpi kernel have this behaviour. > > the netbsd 1.6 image downloadable from http://wiki.qemu.org/Download shows > the same problems, e.g. when started with: > > qemu -drive file=small.ffs -net nic,model=pcnet I can't get this image to work at all, it does not find /usr for me, can't run /etc/rc (/etc is basically empty) and asks for a shell to run. Can you provide some reproducer for me to test with? I know very few about *bsd and their configurations, so a small test image (or a way to build one) with simple instructions is preferrable. I guess we'll have to bisect this issue to find what changed between 0.15 and 1.0 which broke things. Besides, is it really qemu or kvm? Does -enable-kvm and -no-kvm change anything? > 2. freebsd 7 and 8 > > when trying to mount the root filesystem, the kernel outputs only a > seemingly endless number of DMA timeout errors (both use ide), in about > 50% of all boots. downgrading makes them work. Again, the same. I know that debian kfreebsd works just fine, because I use it locally with qemu-kvm to build/test debian packages I maintain. For a quick test I booted freebsd8 image I had from some previous experiments, and it boots fine from ide-emulated drive in qemu-kvm 1.0 > 3. openbsd 4.4 and openbsd 4.5 > > both of these end up in the kernel debugger after a "panic: pci_make_tag: > bad request", which sems to be an acpi-related function. > > downgrading to 0.15.1 fixes this. Ditto, do you have some reproducer for this? > 4. scsi does not boot > > apparently, the ability ot boot from scsi has been removed deliberately. > the problem is that the only workaround for this is the use of a non-free > firmware file by lsi logic, which is hard to locate because the cards are > long past EOL. and, well, it's not even redistributable. > > this of course hampers converting vms from other products, as these often > use the lsi logic controller for better performance than ide, but these > vms no longer boot in 1.0. > > downgrading to 0.15.1 makes it work again, as 0.15.1 still has the ability > to boot from scsi. The situation with scsi is two-fold. Note that scsi emulation has been broken for ages, I think it was since the beginning, and it does not really work with several guests already. This is why, say, Redhat dropped whole scsi support entirely from their qemu[-kvm] packages, -- that was done in order to stop support requests coming due to non-functional subsystem. We still have a bug in debian with a CVE ID assigned - bug within scsi subsystem. Using a broken subsytem for main storage is not a good idea at all ;) Now, I'm not trying to force anyone to do something one way or another, hopefully it is obvious. That's why I keep scsi enabled still, even if I wanted to disable it the same way redhat did, wanted several times. But the boot issue is somewhat similar to another issue: there once was kqemu, an in-kernel qemu accelerator, which got dropped from qemu and it has been suggested to use hardware-assisted virtualization instead of that hack. Sure, at that time lots of users relied on kqemu, especially since VT-supporting hardware wasn't common. So we had 3 choices: 1) ignore the issue and move on following upstream, 2) stay with kqemu- supported version and stop updating the package, and 3) forward-port the subsystem which upstream has dropped. Here we have exactly the same one-of-3 choice, and I'm not sure I can do anything but 1). Re-surrecting extboot for one or two more versions may be a good idea, but I can't support it forever (if at all - I haven't looked at how difficult it will be to patch it back). > assuming 1..3 are just some bug(s), #4 is especially troubling, because > debian will be unlikely to redistribute the option rom that is suggested > as a workaround, so will only support vms with ide. Don't forget there's also ahci nowadays. Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
