qemu-block
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-block] [Qemu-devel] storing machine data in qcow images?


From: Kashyap Chamarthy
Subject: Re: [Qemu-block] [Qemu-devel] storing machine data in qcow images?
Date: Thu, 24 May 2018 11:58:49 +0200
User-agent: Mutt/1.9.2 (2017-12-15)

On Mon, May 21, 2018 at 05:33:22PM -0300, Eduardo Habkost wrote:
> On Mon, May 21, 2018 at 09:18:17PM +0100, Daniel P. Berrangé wrote:

[...]

(Just catching up with this thread.)

[...]

> > > I have very specific goal here: the goal is to make it less
> > > painful to users when OpenStack+libvirt+QEMU switch to using a
> > > different machine-type by default (q35), and/or when guest OSes
> > > stop supporting pc-i440fx.  I assume this is a goal for OpenStack
> > > as well.
> > > 
> > > We can make the solution to be more extensible and solve other
> > > problems as well, but my original goal is the one above.
> > 
> > Configuring the machine type is just one thing that users
> > would do with OpenStack though.  A simple example might be
> > 
> >     openstack image set \
> >          --property hw_disk_bus=scsi \
> >      --property hw_vif_model=e1000e

[...]

> > Setting a non-default machine type is one extra prop
> > 
> >     openstack image set \
> >          --property hw_machine_type=q35
> >          --property os_distro=fedora26
> 
> Nice.  Are these just hypothetical examples, or something that
> already works?

No, not hypothetical -- they actually work _today_, and customers
actively use it in production as we speak.  Machine type could be set in
two ways in OpenStack.  One is as Dan noted above, which is *per* disk
image.  The other is per Compute node (where QEMU instances are
launched), via setting a config attribute in a file
(/etc/nova/nova.conf):

        [libvirt]
        ...
        hw_machine_type=x86_64=pc-q35-2.9

The above means _all_ QEMU instances launched on that Compute node will
get 'pc-q35-2.9' machine type.

[...]

-- 
/kashyap



reply via email to

[Prev in Thread] Current Thread [Next in Thread]