* Markus Armbruster (arm...@redhat.com) wrote: > Eduardo Otubo <eduardo.ot...@profitbricks.com> writes: > > > This first patch extends the command line option `-writeconfig <file>' to a > > command on HMP and QMP monitors. This is useful when live migrating after a > > series of device hot plug events. One can just generate an updated config > > file > > for the vm, transport it to the target host and start the vm with > > `-readconfig > > <file>'. > > > > The second patch re-includes the reference of the memory object on the > > config > > file generated. > > The high-level idea of having QEMU regurgitate its configuration for the > migration target sounds nice, but there are several issues with > regurgitating QemuOpts state with writeconfig: > > 1. Our needs have outgrown QemuOpts' design. We have accumulated > various hacks and work-arounds to make do, and it's still not enough. > Instead of adding more, I want to revise its design. The work has > started, but it'll take some time. Adding creative new uses of > QemuOpts while this work is in progress can only make it harder. > > If this issue was the only one, I'd take the hit for the team. > > 2. Transmitting configuration at the beginning of migration doesn't > fully solve the problem. What about configuration changes during > migration? Think of hot plug. Doesn't mean transmitting > configuration is a bad idea, only means there's more to the problem > than a naive observer might think. > > In my opinion, the proper solution is to transmit configuration > information in the migration stream, complete with updates as it > changes. Hard to do, which is why it hasn't been done. > > If we can't have the proper solution now, a less-than-ideal partial > solution may still be better than nothing.
That's a separate problem from the one Eduardo is trying to solve; I wouldn't trust migration to survive a device hotplugged during the migration as it is. So I wouldn't worry about it as a reason against this series. > 3. The accuracy of QemuOpts information is doubtful. > > Completeness: only certain kinds of configuration are done with > QemuOpts. Incompleteness makes -writeconfig less useful than it > could be, but it's still useful. Monitor command writeconfig could > be similarly useful. > > Correctness: configuration gets stored in QemuOpts when we parse > KEY=VALUE,... strings. It can also be constructed and updated > manually. At certain points in time, bits from QemuOpts are used to > actually configure stuff. > > Example: -device creates an entry in the "device" configuration > group, which is later used to actually create and configure a device > object. > > My point is: whenever we manipulate the actual objects, we may > invalidate information stored in QemuOpts. We can try to keep it in > sync, and we do at least sometimes. But this is a game we can only > lose, except for the period(s) of time where QemuOpts is all there > is, i.e. before actual objects get created. Note that -writeconfig > runs before objects get created, so it's not affected by this issue. > > Out-of-sync QemuOpts is harmless unless something relies on it being > accurate. I know we currently rely on QemuOpts IDs to catch > duplicate IDs for some of the configuration groups. I doubt there's > much else. > > If we add your monitor command, out-of-sync QemuOpts goes from > harmless to serious bug. In other words, we'd create a new class of > bugs, with an unknown number of existing instances that are probably > hard to find and fix. Probably a perpetual source of new instances, > too. > > Feels like a show stopper to me. Hmm this does seem a bigger problem. Dave -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
