On Thu, 2010-06-10 at 10:23 +0200, Gerd Hoffmann wrote: > > I may have been a bit misleading here. What we really want to do is use the > > same matching algorithm as is used by the rest of the device state. > > Currently > > this is a vmstate name and [arbitrary] numeric id. I don't remember whether > > there's a convenient link from a device to its associated vmstate - if there > > isn't there probably should be. > > DeviceState->info->vmsd->name for the name. > Dunno about the numeric id, I think savevm.c doesn't export it.
Ok, we can certainly do <vmsd->name>.<vmsd->instance>\<driver string>. It seems like this highlights a deficiency in the vmstate matching though. If on the source we do: > pci_add addr=4 nic model=e1000 > pci_add addr=3 nic model=e1000 Then we start the target, ordering the nics sequentially, are we going to store the vmstate into the opposite nics? AIUI, libvirt does this correctly today, but I don't like the idea of being required to remember the history of a vm to migrate it. Alex -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
