kvm client freezes on shutdown/poweroff

[Ztoragefool]

hello,

anyone experienced tcl guests freezing right after shutdown process?

what i am running:
  - kmv server (tinycore 64bit)
  - bridged network (enforced tap interfaces won´t alter the bridge´s mac addr)
  - simple tcl 32bit guests booting from cdrom image

last test: started 5 guests the same way. once they were up, i´ve just let them shut down. four guests went down and closed their window.  

one guest (the 3rd, so it´s rather random) froze after running trough the shutdown process and displaying it´s last message (sth. like "request system poweroff"). had to "kill -9" it. not sure what it does to the machine if i let it run (cpu, memory... tap device still was there, cpu looks buisy at 33-100%) or which inconsistencies would be left after killing...

especially annoying if one forgets to unfocus the guest shutting down - found no way to get my console back from the frozen machine.

any known cure on this?

[maro]

Gee there are quite a few potential reasons for this. I'm a regular user of QEMU, mostly v0.11.1 on a XP host as it still supports KQEMU. But I'm also using it on Linux hosts. Due to the hardware currently available to me I've only used KVM a few times. On the odd occasion I have noticed a kernel panic or some other problem at shudown time. I don't recall that those were reproducable.

But if you want to get more to the bottom of it I'd suggest you consider:

• The QEMU version in the TC 3.x repository (i.e. v0.12.2) is not up to date (as v0.12.5 is the last patch release in the 0.12 series and v0.13.0 was released about a month ago). I can't really offer any insight whether that would make a difference, but clearly quite a few bugs are getting squashed with each new release.
• The KVM module is tied to the kernel. Again our kernel version (ie. 2.6.33.3) is not the most recent one.
• If I would be in your situation and would like to see whether upgrading might be helpful I'd go and re-compile QEMU from the latest (stable) source. An alternative would be to try your setup with a different distribution: The candidate I'd probably choose would be FC14 on the basis that quite a few QEMU developers are working for RH and therefore FC14 is likely to be used a fair bit by those folks. I'm pretty sure that v0.13.0 is already in their repository. Furthermore using a more recent kernel (e.g. 2.6.35) should not be a disadvantage. Another plus would be that if I would want to raise a bug report against QEMU I would probably not get the standard answer to use a more recent version for a re-test.

So in summary not much direct help from my end, but I'm afraid your issue might just be too specialised to expect much from the probably small crowd of users that have a similar setup as yourself.

[Ztoragefool]

... in summary probably the most appropiate tips, given an estimated small crowd of users having a similar setup... THANKS!

FC 14 -- Fedora?

anyway, a´ve tried some distros recently, none made me reach more than 50% of my goals out of the box. there´s always been something buggy, unprepared or otherwise strange in some way, which urges me to dive in deeper. so i decided to keep with tiny, because of it´s beloved strengths and because i feel, diving in would make me learn it the LINUX way, not some sweetened redhat, ubuntu, name it flavour... probably not the easiest way, but i am fed up with relying on buggy, rancid sugar.

ok, so this is the point where i get myself the toolchain and some weird sources and begin compiling myself... geronimooo

[maro]

FC14 is indeed Fedora Core 14.

On the risk of getting off-topic:
I tend to agree with the sentiment you expressed in reply #2. Most other distributions are getting fairly "heavy" due to all the bloat they incurr in the attempt to be all things to all people (and in particular to be "frinedly" to newcomers). More bloat means more bugs IMHO and in "bigger" systems it can be much harder to get to the bottom of things.

I just find it at times helpful to boot a live Ubuntu or live FC system to check out some details how "the others are doing things". I used to have a WUBI installation of Ubuntu stored on a NTFS disk and could either boot it natively (instead of XP) or run the same in a VM (using VBox or QEMU). I might do some more of those (with some other distributions) as I don't have to partition any disk for it. It's just one big file (e.g. 5G) and if I don't like it or need the space it's gone within a second. None of those are my preferred system but it can be helpful to take a quick look into it for comparison (and sometimes as a reminder of how not to do it).