On 05/16/2011 08:00 AM, Daniel P. Berrange wrote:
@@ -369,7 +648,7 @@ cleanup:
virDomainObjUnlock(vm);
if (event)
qemuDomainEventQueue(driver, event);
-qemuDriverUnlock(driver);
+qemuMigrationCookieFree(mig);
>>>
>>> Umm, did you really i
On Mon, May 16, 2011 at 02:05:13PM +0100, Daniel P. Berrange wrote:
> On Thu, May 12, 2011 at 01:17:21PM -0600, Eric Blake wrote:
> > On 05/12/2011 10:04 AM, Daniel P. Berrange wrote:
> > > The migration protocol has support for a 'cookie' parameter which
> > > is an opaque array of bytes as far as
On Thu, May 12, 2011 at 01:17:21PM -0600, Eric Blake wrote:
> On 05/12/2011 10:04 AM, Daniel P. Berrange wrote:
> > The migration protocol has support for a 'cookie' parameter which
> > is an opaque array of bytes as far as libvirt is concerned. Drivers
> > may use this for passing around arbitrary
On 05/12/2011 10:04 AM, Daniel P. Berrange wrote:
> The migration protocol has support for a 'cookie' parameter which
> is an opaque array of bytes as far as libvirt is concerned. Drivers
> may use this for passing around arbitrary extra data they might
> need during migration. The QEMU driver need
The migration protocol has support for a 'cookie' parameter which
is an opaque array of bytes as far as libvirt is concerned. Drivers
may use this for passing around arbitrary extra data they might
need during migration. The QEMU driver needs to do a few things:
- Pass hostname/uuid to allow stri
On 05/11/2011 03:09 AM, Daniel P. Berrange wrote:
> The migration protocol has support for a 'cookie' parameter which
> is an opaque array of bytes as far as libvirt is concerned. Drivers
> may use this for passing around arbitrary extra data they might
> need during migration. The QEMU driver need
The migration protocol has support for a 'cookie' parameter which
is an opaque array of bytes as far as libvirt is concerned. Drivers
may use this for passing around arbitrary extra data they might
need during migration. The QEMU driver needs todo a few things:
- Pass hostname/uuid to allow stric
