[libvirt-users] F13-x86_64 - New version of qemu in raw virt repo breaks virsh and virt-manager?

[Mike Hinz]

On Sun, 2010-08-15 at 22:21 +0200, Matthias Bolte wrote:
> 2010/8/15 Mike Hinz <mike.hinz at yr20.com>:
> > Without actually thoroughly thinking about it, I updated my system
> > yesterday with the latest qemu-kvm.  rpm -qa shows
> >
> >  qemu-kvm-0.13.0-0.5.20100809git25fdf4a.fc13.x86_64

> > Now when I attempt to start a domain that was working perfectly well
> > prior to this update, I get the following:
> >
> > virsh # start winxp1
> > error: Failed to start domain winxp1
> > error: internal error Process exited while reading console log output:
> > Supported machines are:
> > pc         Standard PC (alias of pc-0.13)
> > pc-0.13    Standard PC (default)
> > pc-0.12    Standard PC
> > pc-0.11    Standard PC, qemu 0.11
> > pc-0.10    Standard PC, qemu 0.10
> > isapc      ISA-only PC

> 
> I think this is a machine type compatibility issue between your
> previous and current QEMU version.
> 
> See 'virsh dumpxml winxp1' for a line like this:
> 
> <os>
>   <type arch='i686' machine='pc'>hvm</type>
> </os>
> 
> The machine attribute will probably have a value that your current
> QEMU doesn't understand anymore. Therefore, it complains about the
> machine type and list the ones it understands.
> 
> > Is there a way to get around this and somehow use my existing domains
> > with this updated version of qemu-kvm?
> 
> You can try to 'virsh edit winxp1' and replace the value of the
> machine attribute with something your current QEMU understands, e.g.
> 'pc-0.13'.
> 
> > Interestingly, just out of curiosity, I've started a new installation of
> > a WinXP vm.  This seems to be going perfectly well so far, so I assume
> > that the issue is only with domains previously created with the older
> > version of qemu??
> 
> If you define a new guest then libvirt (actually virt-install called
> from virt-manager) will pick a machine type that your current QEMU
> understands. Therefore, a newly defined guest works.
> 
> Matthias

Matthias, thanks very much for the above.  You were exactly correct.  I
edited as you indicated:

  <os>
    <type arch='x86_64' machine='pc-0.13'>hvm</type>

The original value was:  machine='fedora-13' which was apparently
causing the failure with the new qemu.  

However, this reveals another problem.  I can now startup any of my
Linux based domains with no problem at all after doing the above simple
edit.  However an existing WinXP domain is still problematic.  The
reason goes back to the irritating issue of installing a WinXP guest
somehow messing up the boot sector (at least i think that's what
happens) and as a result, you have to leave the CDROM attached and
pointing to an .iso of a WinXP installation disk.  

Now the existing WinXP domain cannot start as it gets hung during the
boot process.  I've tried configuring the guess to boot from either the
CD (.iso image) or the hard drive and both options now hang while
attempting to boot.  The WinXP guest that I just freshly created boots
fine from the hard drive, so apparently that issue is fixed with the new
qemu.  However, my question is:  Is there a way to fix the old WinXP
guest image so that it can boot?

Thanks in advance for any help on this point!

Mike.