qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Re: [patch 2/3] Add support for live block copy


From: Avi Kivity
Subject: Re: [Qemu-devel] Re: [patch 2/3] Add support for live block copy
Date: Wed, 23 Feb 2011 14:46:40 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Lightning/1.0b3pre Thunderbird/3.1.7

On 02/22/2011 11:11 PM, Anthony Liguori wrote:
The commit file is considered reliable storage for the result of image
switch operation. Think of the following scenario:

- mgmt app requests live copy of guests ide1-hd0
from /a/image.img to /b/image.img.
- mgmt app dies.
- guest switches to /b/image.img, /a/image.img is outdated.
- guest dies.

Notifying the switch via QMP would not be reliable in this case.

But this is true of any number of operations in QEMU such as hotplug where if a management tool dies after requesting hotplug and then the guest dies before the management tool reconnects, it's never known whether it's truly connected or not.

The only way to robustly solve this is for QEMU to maintain a stateful config file.

Or, the management tool can remember that it tries to hotplug, reconnect, query qemu (or just retry), and proceed according to the result:

- insert record in config for the new device, status = inactive
- commit
- tell qemu to hotplug
<crash>
- restart, read database, see inactive device
- query qemu
- if device is there, mark as active, commit
- else, tell qemu to hotplug, when successful, mark as active, commit


  A one-off for this particular command doesn't seem wise to me.

Strongly agreed.

--
error compiling committee.c: too many arguments to function




reply via email to

[Prev in Thread] Current Thread [Next in Thread]