Mark McLoughlin wrote:
So, when libvirt creates a guest for the first time, it makes a copy of
the device tree and continues to use that even if qemu is upgraded.
That's enough to ensure compat is retained for all built-in devices.
However, in order to retain compat for that SCSI device (e.g. ensuring
the PCI address doesn't change as other devices are added an removed),
we're back to the same problem ... either:
1) Use '-drive file=foo.img,if=scsi,pci_addr=foo'; in order to figure
out what address to use, libvirt would need to query qemu for what
address was originally allocated to device or it would do all the
PCI address allocation itself ... or:
2) Don't use the command line, instead get a dump of the entire
device tree (including the SCSI device) - if the device is to be
removed or modified in future, libvirt would need to modify the
device tree
The basic problem would be that the command line config would have very
limited ability to override the device tree config.
After libvirt has done -drive file=foo... it should dump the machine
config and use that from then on.
To combined to a single thread...
How do you add a new attribute to the device tree and, when a supplied
device tree lacking said attribute, distinguish between a device tree
from an old version of qemu (i.e. use the old default) and a partial
device tree from the VM manager (i.e. use the new default) ?
Please define "attribute". I don't follow what you're asking.
NB the device tree contains no host configuration information.
So, it wouldn't e.g. include the path to the image file for a block
device? That would always be specified on the command line?
No, the IDE definition would contain some sort of symbolic node name. A
separate mechanism (either command line or host config file) would then
link a image file to the symbolic name.
libvirt should really never worry about the machine config file for
normal things unless it needs to change what devices are exposed to a guest.
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
