Re: [Qemu-devel] [PATCH 22/22] machine: introduce -machine-def option to define a machine via config

[Daniel P. Berrange]

On Thu, Jun 10, 2010 at 06:48:42PM +0100, Daniel P. Berrange wrote:
> On Mon, Jun 07, 2010 at 07:50:14PM -0500, Anthony Liguori wrote:
> > On 06/07/2010 06:52 PM, Anthony Liguori wrote:
> > >Since we have MachineCore and can represent a machine entirely via default
> > >options, we can introduce a new option that let's us dynamically register a
> > >machine based on those options.
> > >
> > >For instance, we could add the following to target-x86_64.conf:
> > >
> > >[machine-def]
> > >  name = "pc-0.11"
> > >  desc = "Standard PC"
> > >  acpi = "on"
> > >  pci = "on"
> > >  cpu = "qemu64"
> > >  max_cpus = "255"
> > >  virtio-blk-pci.vectors = "0"
> > >  virtio-serial-pci.max_nr_ports = "1"
> > >  virtio-serial-pci.vectors = "0"
> > >  ide-drive.ver = "0.11"
> > >  scsi-disk.ver = "0.11"
> > >  PCI.rombar = "0"
> > >
> > >What's really exciting, is that a user can then define their own machines
> > >that better suite their desires:
> > >
> > >[kvmpc]
> > >  name = "kvmpc"
> > >  accel = "kvm|tcg"
> > >  ram_size = "512M"
> > >  max_cpus = "64"
> > >  sockets = "16"
> > >  default_drive = "virtio"
> > >
> > >I'd eventually like to move all PC compatibility machines to the default
> > >config but for now, I wanted to keep this simple.
> > >
> > >Signed-off-by: Anthony Liguori<address@hidden>
> > >   
> > 
> > From the perspective of a tool like libvirt, I think there are a couple 
> > ways it could handle something like this and I think it's worth 
> > discussing the options.
> > 
> > Assume we move all the compat machine definitions into a config file, 
> > since libvirt presumably uses -nodefconfig today, it could simply 
> > include it's own machine definitions for each qemu version based on the 
> > definitions we ship.  That makes sure that the definition is always 
> > static for libvirt.
> 
> Due to a screwup on my part, we don't currently use -nodefconfig
> but we should be. I had originally thought '-nodefaults' turned off
> all defaults, but I see it only does defaults hardware, but not
> default configs. 
> 
> > Another option would be for libvirt to not use -nodefconfig, and instead 
> > to let the user's global configs be read.  libvirt would then read the 
> > config file from the running qemu instance to sync it's state up.
> 
> The tricky thing I'm seeing here is the scope of the stuff you can 
> put in the configuration files. 
> 
> On the one had there are config options that effectively provide new 
> capabilities to the QEMU binary eg new machine types, new CPU definitions.
> These don't cause any trouble, since that are a complete no-op unless you
> launch a guest that actually requests to make use of them eg by adding a
> -M mycustommachine or  a  -cpu mycustomCPUmodel flag. A '-M pc-010' guest
> will never be impacted by fact that you added some new machine types in
> the global config.
> 
> On the other hand there are config options that immediately change the 
> virtual hardware in all guests launched, eg if I edit the 
> /etc/qemu/target-i386.conf and add
> 
>   [drive]
>     if = "ide"
>     file = "foo.iso"
> 
> then every single guest gets a new piece of hardware, which is what we
> tried to avoid with the '-nodefaults' flag already.
> 
> > The later option is a bit more work up front but longer term, I think it 
> > addresses a couple things nicely.  It provides a way for a user 
> > specified config to co-exist with libvirt.  It also let's tools tweak 
> > power config options in a way that's compatible with libvirt.
> > 
> > If libvirt can embed the qemu config description in its own XML, then 
> > there is no problem for libvirt to recreate the system on a different 
> > box even if the global configuration is different.
> 
> If the global config is just adding new capabilities (machine types,
> cpu types, etc) I see no problem with having these loaded by default
> for any libvirt guest.
> 
> When the global config can add extra hardware (eg drives) this becomes
> very tricky to re-concile, which is exactly why we had '-nodefaults'
> to turn off extra global hardware. 
> 
> We want all hardware libvirt knows about to be visible in the XML. 
> eg, if the default config contained a [drive] section, you'd expect 
> that to appear as a <disk> in libvirt XML. So if we parsed the default 
> global config to sync it to the libvirt XML, when we come to launch the
> guest, we have even more fun figuring out which of the disks in the XML
> config needs a '-drive' on the ARGV, and which don't need any arg because
> they're in the global config. To make that practical we'd need to read 
> the global config, turn it into libvirt XML, and then launch the guest
> with -nodefconfig and just use -drive as normal for everything. But then
> we loose useful things like new machine types & cpu types :-(
> 
> Is it practical to a way to separate the global config into two global
> configs. One config that is used to define extra capabilities (machine
> types, cpu types, etc) that on their own are guarenteed to never impact
> any existing guest config. One that is used to add default hardware 
> (disks nics, etc) which clearly does impact every guest.
> 
> Then, we could let the global capabilities config be in effect at all 
> times, QEMU wouldn't even need a way to turn that off. The global
> hardware config could be enabled/disable as per the needs of the mgmt
> app, reconciled with their config as required.

Actually thinking about it some more, it doesn't require a separation of
global configs. Instead we're just use my capabilities patches to query
the desired CPU & machine definitions from the global, and write them out 
to a new config and then use -nodefconfig to turn off the global config,
and -readconfig re-add just the bits of the global config we wanted.


Daniel
-- 
|: Red Hat, Engineering, London    -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org        -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|