[Top][All Lists]

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

Re: [Qemu-devel] [PATCH 2/4] block: add block topology options

From: Markus Armbruster
Subject: Re: [Qemu-devel] [PATCH 2/4] block: add block topology options
Date: Tue, 09 Feb 2010 16:26:33 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)

Anthony Liguori <address@hidden> writes:

> On 02/05/2010 07:09 AM, Christoph Hellwig wrote:
>> On Wed, Feb 03, 2010 at 01:00:47PM -0600, Anthony Liguori wrote:
>>> But I don't think this is the wrong place to do it.  The
>>> BlockDriverState reflects that backing device, not the emulated device
>>> itself.  In this case, you're trying to set a property of the emulated
>>> device.
>> I think that's very borderline.  While the emulated device exposes these
>> properties, they are in fact a property of the backing storage, the
>> right sector and min/max I/O sizes are determined by the backing storage
>> device.
> It's guest visible state that should be configured based on the
> properties of the backing store.
> However, as you said, live migration complicates things.
> drive is not an optimal interface because it mixes host and guest
> state.

Qdev separates guest and host stuff.  -device does guest, -netdev,
-chardev, -drive if=none do host.  Unfortunately, -drive can also do
host, with other values for parameter if.  A clean, host-only -blockdev
for use with -device would be nice to have.

>         But the subset of -drive that you normally use should be
> independent of the guest.

To be precise: those properties that make sense with if=none.

>                            For instance, with:
> -drive file=/home/anthony/foo.img,cache=off,aio=native,id=foo -device
> virtio-blk-pci,drive=foo

There's an implied if=ide, which means it's mixed host and guest stuff.

> file, cache, and aio are all host properties.  They have no visible
> impact to the guest and if I change those properties during live
> migration, they take affect without the guest noticing
> These topology options still can be specified via -drive, but the
> proper way of splitting things would have them as part of the -device
> option.  During live migration, things on the -device side inherited
> as part of the live migration process.

If it's guest-visible, it should live in guest state (qdev device
state), and be configured with -device.  Else, it should live in host
state (block driver state), and be configured via -drive if=none (or
-blockdev once we have it).


reply via email to

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