Re: [Qemu-devel] q35 and ahci

[Daniel P. Berrange]

On Tue, Jul 17, 2012 at 11:47:14AM -0400, Jason Baron wrote:
> On Tue, Jul 17, 2012 at 09:31:46AM -0600, Eric Blake wrote:
> > > Update on q35 testing with various os's.
> > > 
> > > Linux
> > > -----
> > > -RHEL6.3 installs + runs 
> > > -Fedora 16 install + runs
> > > -Fedora 17 - squashfs errors 
> > >    running on already installed f17 seems ok.
> > 
> > Pardon my high-level question (I haven't been following q35 threads
> > closely), but I just looked at http://wiki.qemu.org/Features/Q35 for the
> > first time.  Am I correct that all we are doing is adding a new machine
> > model, but that it will still be possible to select the older machine
> > model for migration compatibility when migrating a guest in from an
> > older qemu?  Does libvirt need to do anything special to its generated
> 
> yes, right now its specified as -M pc_q35
> 
> > command line to specify the old vs. the new machine model?
> > 
> 
> The current command line I'm using something such as:
> 
> $ /usr/local/bin/qemu-system-x86_64  -name "f16" -M pc_q35 -m 1G -smp 4
> -hda ./f16.img --enable-kvm  -bios <path>/q35-seabios/out/bios.bin
> -acpitable file=<path>/q35-seabios/out/q35-acpi-dsdt.aml  -monitor stdio
> 
> So it might be nice to avoid the '-acpitable' flag. Perhaps, we can
> teach qemu to pull in the correct acpitable depending on the -M
> specification...

Absolutely, this requirement to set magic -bios and -acpitable params
when using '-M pc_q35' is really horrible. If QEMU requires a different
BIOS setup for this machine type, then it should just do the right
thing itself, since presumably it knows what it wants better than
libvirt or any other mgmt app does.

Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|