On Sat, Dec 17, 2011 at 04:47:04PM +0400, Michael Tokarev <[email protected]>
wrote:
> Note that 1.0 is in unstable already, so we don't have 0.15 anymore.
yeah, I made a copy, and I am so happy for the archival server too... :)
> > 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.
Here too, yes, but I didn't really dig into that because ide works fine for
(my) netbsd, and I was only concerned about networking.
> Can you provide some reproducer for me to test with? I know very few
I could, but my images are pretty big (0.5gb compressed), which is a bit of a
pain to uploasd to something fast.
maybe you could try the normal netbsd installcd? thre network install cd
should be small, and doesn't need to be installed to disk to test for the
network.
I read on the internets that you need the noacpi kernel, but in fact,
in 0.15 I used the normal kernel (-GENERIC). I did switch to the noacpi
kernel, with no change, so I assume it really doesn't matter.
as for pcnet32, the device is called "pcn0" in both ifconfig -a and during
the kernel book. e1000 is proabbly em0, I forgot.
if you don't know whta bootcd to download I can dig that out for you - but I
am probably as good as netbsd as you are :)
> Besides, is it really qemu or kvm? Does -enable-kvm and -no-kvm
> change anything?
I think tried both "kvm" and "qemu", so I assume it happens with kvm+kvm
and qemu without kvm.
(...)
tried it out with pcnet, didn't test any others:
qemu: no pcn0
qemu -enable-kvm: no pcn0
kvm: no pcn0
kvm -no-kvm: no pcn0
going back to qemu-kvm 0.15.1, plain "kvm" makes it appear.
> > 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
Interesting - also for freebsd, I didn't compile or configure my own kernel,
however...
qemu: works
qemu -enable-kvm: works
kvm -no-kvm: work
kvm: doesn't work
however, I found that it's definitely a race condition, and now happens
less often than 50% (with -snapshot btw.), so theswe resutls are very
unreliable, I only tried it out 3 times.
> 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
hmmm... yeah, it "often" boots here now, but not always. weird.
> > 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?
again, same issue as with the others, the freebsd images I have are 2gb
compressed, the others 0.5gb, and my upstream bandwith is far more limited
than my downstream.
> > 4. scsi does not boot
> >
> > downgrading to 0.15.1 makes it work again, as 0.15.1 still has the ability
> > to boot from scsi.
>
> Using a broken subsytem for main storage is not a good idea at all ;)
well, the only alternative is ide, as ahci is far more broken. at leats our
linux and windows guests survived many snapshots/resumes with lsi, but not
a single ahci one...
> Now, I'm not trying to force anyone to do something one way or another,
for *my* purposes, ahci would, if it worked, be a perfect replacement,
preferable to scsi.
the problem is that in 0.15.1, ahci doesn't survive a loadvm at all, giving
I/O errors throughout with linux guests (and probably somehting similar with
windows), and in 1.0rc4, qemu refuses to take snapshots.
> 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.
i would all be nice (for me :), *iff* there were a replacement, e.g. ahci.
> 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.
well, the whole point of virtualisation is not so much playing around with
other osses, but with stability, i.e. being able to boot old images. of
course, I also have old openbsd images simply for portability testing of
my packages...
this is why removing hardwrae support is pretty evil - it basically tells
users to use another virtualisation solution, one that still works next
year.
thats why I like the -machine switch, as it gives me the right message:
"yes, we do support old hardware configs".
Now, changing commandlien syntax every release is not so great either, but
at leats to me, not at all a blocker. Having to reinstall vms every second
release makes kvm useless to me, and, I suspect, many other users too.
> 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).
Well, again, for me, ahci support would be just as useful, or even more
useful. But ahci has to work first.
<rant>
Now, if ide gets removed in two releases, and ahci in seven, for the same
reasons ("I can't support it forver"), then I would _personally_ say thats
pretty lame, and _professionally_ say we go back to vmware or virtualbox,
no matter how painful those products are - at least they *do* run my
windows 2000 vm from so many years ago.
this is not an idle threat, I hate virtualbox becuse it's so superawkward,
and I hate vmware because of so many things, not the leats it not being free
software, and I invested many days of my life to port all my vms to kvm a
month or so ago (and then qemu), because... it's just heaven, modulo some
dirtyness around that will surely get fixed. really having to go back
threatens me, it scares me, i will lose sleep even contemplating the concept
of "going back". omg. :)
but kvm suddenly looks like a moving target - I don't want to port my vms
to every new kvm version because some emulated hardware is deemed too
annoying to support.
of course, I might have had bad luck, but nowehere did qemu warn about
lsi being broken or deprecated, at least not where I looked. unlike ahci,
which was clearly marked as experimental and quite clearly was broken.
</rant>
> > as a workaround, so will only support vms with ide.
>
> Don't forget there's also ahci nowadays.
There was ahci in 0.15 already, but ahci is close to useless until it
survives a suspend (savevm/loadvm). in 0.15, it causes crashes, and in
1.0, it tells me ahci doesn't support migration (even when I just use
savevm/loadvm) and thus fails to work as well.
yeah, please give me ahci. please please :-)
as regarding test images, if the boot cds don't do (I can fiond them for
you), then I can presumably upload either my images (nothing private in
there), or make smaller new ones, but that will take considerable (real)
time. it has to be done though if thats the onyl way to get it working, I
don't want to run qemu 0.15 forever.
thanks for your work btw.!
--
The choice of a Deliantra, the free code+content MORPG
-----==- _GNU_ http://www.deliantra.net
----==-- _ generation
---==---(_)__ __ ____ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / [email protected]
-=====/_/_//_/\_,_/ /_/\_\
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
