[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).
[...]