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<aligu...@us.ibm.com> > > > > > > > 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 :|