Bug 479407 - KVM guest locks up after upgrade to F10
Summary: KVM guest locks up after upgrade to F10
Keywords:
Status: CLOSED DUPLICATE of bug 475598
Alias: None
Product: Fedora
Classification: Fedora
Component: kvm
Version: 10
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Glauber Costa
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-01-09 12:33 UTC by Pierre Ossman
Modified: 2009-01-12 12:47 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-01-12 12:47:24 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
libvirt log (677 bytes, application/octet-stream)
2009-01-09 17:28 UTC, Pierre Ossman
no flags Details

Description Pierre Ossman 2009-01-09 12:33:35 UTC
I upgraded a F8 host with a bunch of F9 guests to F10 (both host and guests). Now I am plagued by guests hanging completely and having to forcefully restart them periodically.

I've turned of console blanking in hopes of seeing a panic, but there is no output when the machine locks up.

Doing a strace on the qemu process gives this:

timer_gettime(0x1, {it_interval={0, 0}, it_value={0, 0}}) = 0
timer_settime(0x1, 0, {it_interval={0, 0}, it_value={0, 33000000}}, NULL) = 0
select(13, [4 8 10 11 12], [], [], {1, 0}) = 1 (in [11], left {0, 967000})
read(11, "\16\0\0\0\0\0\0\0\376\377\377\377\0\0\0\0\0\0\0\0\0\0\0\0\1\0\0\0\0\0\0\0\0"..., 128) = 128
rt_sigaction(SIGALRM, NULL, {0x408380, ~[KILL STOP RTMIN RT_1], SA_RESTORER, 0x38e900f0f0}, 8) = 0
read(11, 0x7fff0b6db450, 128)           = -1 EAGAIN (Resource temporarily unavailable)

I'm afraid I don't know how to debug this further. Logs on host and guest do not have anything around the time it hangs.

Comment 1 Mark McLoughlin 2009-01-09 16:48:34 UTC
thanks for the report pierre

Could you attach the log file for the guest from /var/log/libvirt/qemu?

Also the "virsh dumpxml" output for the guest? (assuming you're using libvirt)

If you're using a qcow image, could you try convert it to raw and see if that helps?

Comment 2 Mark McLoughlin 2009-01-09 16:52:54 UTC
pierre: also look at bug #479407 and see if any of the suggestions there help

Comment 3 Pierre Ossman 2009-01-09 17:28:03 UTC
Created attachment 328568 [details]
libvirt log

This log is from a machine that had locked up at the time the log was copied.

dumpxml output:

<domain type='kvm' id='5'>
  <name>citroen</name>
  <uuid>118d8b2b-4684-46c5-87fa-9ea9424718c8</uuid>
  <memory>524288</memory>
  <currentMemory>524288</currentMemory>
  <vcpu>1</vcpu>
  <os>
    <type arch='i686' machine='pc'>hvm</type>
    <boot dev='hd'/>
  </os>
  <features>
    <acpi/>
  </features>
  <clock offset='utc'/>
  <on_poweroff>destroy</on_poweroff>
  <on_reboot>restart</on_reboot>
  <on_crash>destroy</on_crash>
  <devices>
    <emulator>/usr/bin/qemu-kvm</emulator>
    <disk type='block' device='disk'>
      <source dev='/dev/system/citroen'/>
      <target dev='hda' bus='ide'/>
    </disk>
    <disk type='block' device='disk'>
      <source dev='/dev/system/samba'/>
      <target dev='hdb' bus='ide'/>
    </disk>
    <interface type='ethernet'>
      <mac address='00:16:3e:00:7a:12'/>
      <script path='/etc/qemu-ifup'/>
      <target dev='virt1'/>
    </interface>
    <input type='mouse' bus='ps2'/>
    <graphics type='vnc' port='5902' autoport='yes' listen='127.0.0.1' keymap='sv'/>
  </devices>
</domain>

Comment 4 Pierre Ossman 2009-01-09 17:29:02 UTC
(and for those casual readers, the storage is an LVM volume)

Comment 5 Pierre Ossman 2009-01-09 17:29:47 UTC
(In reply to comment #2)
> pierre: also look at bug #479407 and see if any of the suggestions there help

That's this bug ;)

Comment 6 Mark McLoughlin 2009-01-09 18:26:11 UTC
(In reply to comment #5)
> (In reply to comment #2)
> > pierre: also look at bug #479407 and see if any of the suggestions there help
> 
> That's this bug ;)

Gah, sorry - bug #475598

Comment 7 Pierre Ossman 2009-01-09 18:45:38 UTC
Thanks. I've changed clock source on all guests. Now we'll just have to wait I guess.

Comment 8 Pierre Ossman 2009-01-12 12:45:42 UTC
It's been running for three days without problems since I changed the clock source, so this is probably a duplicate of bug 475598.

Comment 9 Chris Lalancette 2009-01-12 12:47:24 UTC
OK, I'm going to close it as such.

Chris Lalancette

*** This bug has been marked as a duplicate of bug 475598 ***


Note You need to log in before you can comment on or make changes to this bug.