From: Juan Quintela <quintela@redhat.com>
To: Kevin Wolf <kwolf@redhat.com>
Cc: qemu-devel@nongnu.org, Chris Wright <chrisw@redhat.com>,
kvm-devel <kvm@vger.kernel.org>
Subject: Re: KVM call agenda for Jan 11
Date: Tue, 11 Jan 2011 14:41:44 +0100 [thread overview]
Message-ID: <m31v4jblrb.fsf@trasno.org> (raw)
In-Reply-To: <4D2C3B4D.2090709@redhat.com> (Kevin Wolf's message of "Tue, 11 Jan 2011 12:13:17 +0100")
Kevin Wolf <kwolf@redhat.com> wrote:
> Am 10.01.2011 14:32, schrieb Juan Quintela:
>> Juan Quintela <quintela@redhat.com> wrote:
>>> Juan Quintela <quintela@redhat.com> wrote:
>>>
>>> Now sent it to the right kvm list. Sorry for the second sent.
>>>
>>>> Please send any agenda items you are interested in covering.
>>>>
>>>> - KVM Forum 2011 (Jes).
>>>>
>>>> thanks, Juan.
>>
>> - migration and block devices: a mess.
>> * patches I sent last week: only work for root (for some definition of
>> work)
>> * qemu is used as non-root user.
>> * forcing to have cache=none solves the issue
>
> I need to have a look at the specific problem, but it's hard to imagine
> that cache=none fixes anything reliably.
It uses O_DIRECT, that means that we don't have buffering problems.
I state the problem again:
machine A read 1st block of device.
<and stays without doing anything else>
machine B reads writes lots of places including 1st block
now guest from machine A migrates to machine B
machine A re-reads the 1st block, and lo and behold, it reads the old
contents, not the new ones.
Solutions:
- invalidate all buffers for that block device on machine A after
migration.
* with NFS, just close + reopen the file (and pray that nobody else
has it also opened)
* with block devices: use BLKFLBLK ioctl, and pray that nobody else is
using the device, that device is not a ramdisk, and some more
things. To add injury to insult, you need to be root to be able
to issue that ioctl (technically have CAP_SYS_ADMIN).
O_DIRECT fixes this problem altogether, because there is no buffering,
and if there are not buffers, they can't be invalid O:-)
Notice the "pray" part in the other solutions, we are basically trying
to do a "poor man" DLM, and that is not trivial to do. (althougth our
problem is not the general one, the principles are the same).
Later, Juan.
next prev parent reply other threads:[~2011-01-11 13:42 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <m3pqs5gj17.fsf@trasno.org>
2011-01-10 11:59 ` KVM call agenda for Jan 11 Juan Quintela
2011-01-10 13:05 ` [Qemu-devel] " Jes Sorensen
2011-01-10 13:45 ` Stefan Hajnoczi
2011-01-10 16:46 ` Peter Maydell
2011-01-10 13:32 ` Juan Quintela
2011-01-11 11:13 ` [Qemu-devel] " Kevin Wolf
2011-01-11 13:41 ` Juan Quintela [this message]
2011-01-11 14:43 ` Anthony Liguori
2011-01-13 16:12 ` Avi Kivity
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m31v4jblrb.fsf@trasno.org \
--to=quintela@redhat.com \
--cc=chrisw@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=kwolf@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox