Bug 1066145

Summary:	Using <timer name=hpet present=no> causes arm + ppc64 to break, "Option no-hpet not supported for this target"
Product:	[Community] Virtualization Tools	Reporter:	Richard W.M. Jones <rjones>
Component:	libvirt	Assignee:	Ján Tomko <jtomko>
Status:	CLOSED NEXTRELEASE	QA Contact:
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	unspecified	CC:	acathrow, berrange, danlipsitt, jtomko
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:
Clones:	1066524 (view as bug list)		Environment:
Last Closed:	2014-04-18 13:16:44 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	910269

Description Richard W.M. Jones 2014-02-17 20:17:03 UTC

Description of problem:

qemu-system-arm has an annoying bug since forever where the -help
output mentioned -no-hpet, but if you actually use this flag, qemu
helpfully prints:

  Option no-hpet not supported for this target

If you use the libvirt XML on an ARM guest:

  <timer name=hpet present=no>

meaning "don't include an HPET device", then libvirt adds -no-hpet
to the command line, and qemu-system-arm won't start up.  Of course
ARM has never had a High Precision Timer, and in any case we're
asking not to include one.

I have worked around this in libguestfs by not including this
XML fragment on ARM, but this still looks like it is a bug in
libvirt (and qemu of course).

Version-Release number of selected component (if applicable):

libvirt from git today

How reproducible:

100%

Steps to Reproduce:
1. Compile libvirt from git on ARM.
2. Run: ~/d/libvirt/run libguestfs-test-tool

Actual results:

Original error from libvirt: internal error: process exited while connecting to monitor: Option no-hpet not supported for this target
 [code=1 domain=10]
libguestfs-test-tool: failed to launch appliance

Expected results:

Should probably ignore this.

Additional info:

Comment 1 Daniel Berrangé 2014-02-18 15:07:46 UTC

*** Bug 1066524 has been marked as a duplicate of this bug. ***

Comment 2 Daniel Berrangé 2014-02-18 15:08:49 UTC

Affects multiple architectures, both arm and ppc, probably all non-x86 archs in fact.

Comment 3 Daniel Lipsitt 2014-02-26 00:55:45 UTC

(In reply to Richard W.M. Jones from comment #0)

> I have worked around this in libguestfs by not including this
> XML fragment on ARM, but this still looks like it is a bug in
> libvirt (and qemu of course).

I still see this problem after compiling from libguestfs-1.25.37.tar.gz on Ubuntu Trusty. Should the workaround be present in that release?

Comment 4 Richard W.M. Jones 2014-03-26 14:34:45 UTC

(In reply to Daniel Lipsitt from comment #3)
> (In reply to Richard W.M. Jones from comment #0)
> 
> > I have worked around this in libguestfs by not including this
> > XML fragment on ARM, but this still looks like it is a bug in
> > libvirt (and qemu of course).
> 
> I still see this problem after compiling from libguestfs-1.25.37.tar.gz on
> Ubuntu Trusty. Should the workaround be present in that release?

The workaround is present in current libguestfs, so a newer version
should be OK.

Comment 5 Ján Tomko 2014-04-17 14:57:47 UTC

Upstream patch posted:
https://www.redhat.com/archives/libvir-list/2014-April/msg00730.html

Comment 6 Ján Tomko 2014-04-18 13:16:44 UTC

Fixed upstream:
commit c3725db8d0c1035dc550959c93f8b9aeb78ec1bf
Author:     Ján Tomko <jtomko>
CommitDate: 2014-04-18 15:01:27 +0200

    Only set QEMU_CAPS_NO_HPET on x86
    
    QEMU only supports it on x86, but we've been assuming it for
    all QEMUs when doing QMP capability detection.
    
    https://bugzilla.redhat.com/show_bug.cgi?id=1066145

git describe: v1.2.3-138-gc3725db
Backported to v1.1.3-maint: v1.1.3.4-19-ga91c1f1