From: Michael Tokarev <mjt@tls.msk.ru>
To: Brian Jackson <iggy@theiggy.com>
Cc: KVM list <kvm@vger.kernel.org>
Subject: Re: opening files in exclusive mode?
Date: Sat, 24 Jan 2009 19:39:00 +0300 [thread overview]
Message-ID: <497B4424.50307@msgid.tls.msk.ru> (raw)
In-Reply-To: <740947CD-BE77-4AC5-AF36-92EA0E4A673B@theiggy.com>
Brian Jackson wrote:
> This has been discussed thoroughly on this list at least once in the
> past. It was decided against changing the default for various reasons.
Well, I understand points about changing defaults. I disagree,
because it really hurts to have no warnings whatsoever when, by
a chance, running off an already used block device (it's even
possible to run a guest off a block device mounted on host!),
but that's another topic (I'll take a look at the archives).
> See the original thread for all the reasons, but the ones I remember
> are: it would kill backward compatibility for people that start multiple
> guests from the same source with -snapshot and for people who use qcow
> images with base images.
Well, qcow with base image is easy: there are shared and exclusive
locks out there. Base image gets locked in shared mode, while the
qcow itself is in exclusive.
> It was also suggested that this might be a
> feature better suited for a mgmt application since it likely has a
> better idea of who/how it will be used.
There is, so far, no management application. I for one either run
kvm manually from command line, or use a shell script with a single
command line in it (because the command line becomes quite long).
And it seems most people who experiment with kvm are either doing
the same or are trying libvirt and falling back to bare command line
when that does not work. So that "management application" becomes
the human who runs the whole thing, and who needs this whole feature
in the first place... :)
> It could also disrupt live
> migration.
That's probably true. Again, with some workarounds, or disabling
locking.. I dunno for now.
But the question stands: how about the whole idea about PROVIDING
such an option, to start with?
Thanks!
/mjt
prev parent reply other threads:[~2009-01-24 16:39 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-24 15:03 opening files in exclusive mode? Michael Tokarev
2009-01-24 16:24 ` Brian Jackson
2009-01-24 16:39 ` Michael Tokarev [this message]
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=497B4424.50307@msgid.tls.msk.ru \
--to=mjt@tls.msk.ru \
--cc=iggy@theiggy.com \
--cc=kvm@vger.kernel.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