Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.

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