On Wed, 05/11 13:56, Kevin Wolf wrote:
> Am 11.05.2016 um 13:48 hat Richard W.M. Jones geschrieben:
> > While I remember there is another concern that doesn't seem to be
> > addressed in this patch series. What happens when a guest is paused?
> > I think exclusive locks should be converted to shar
Am 11.05.2016 um 13:48 hat Richard W.M. Jones geschrieben:
> While I remember there is another concern that doesn't seem to be
> addressed in this patch series. What happens when a guest is paused?
> I think exclusive locks should be converted to shared locks in that
> case, since (only while the
While I remember there is another concern that doesn't seem to be
addressed in this patch series. What happens when a guest is paused?
I think exclusive locks should be converted to shared locks in that
case, since (only while the guest is paused) it _is_ safe to fish
around inside the guest's st
Am 11.05.2016 um 11:28 hat Richard W.M. Jones geschrieben:
>
> On Wed, May 11, 2016 at 04:04:40PM +0800, Fam Zheng wrote:
> > On Tue, 05/10 13:22, Daniel P. Berrange wrote:
> > > On Tue, May 10, 2016 at 01:11:30PM +0100, Richard W.M. Jones wrote:
> > > > At no point did I say that it was safe to u
On Wed, May 11, 2016 at 04:04:40PM +0800, Fam Zheng wrote:
> On Tue, 05/10 13:22, Daniel P. Berrange wrote:
> > On Tue, May 10, 2016 at 01:11:30PM +0100, Richard W.M. Jones wrote:
> > > At no point did I say that it was safe to use libguestfs on live VMs
> > > or that you would always get consiste
On Wed, May 11, 2016 at 10:04:12AM +0200, Markus Armbruster wrote:
> "Daniel P. Berrange" writes:
>
> > On Tue, May 10, 2016 at 01:11:30PM +0100, Richard W.M. Jones wrote:
> >> At no point did I say that it was safe to use libguestfs on live VMs
> >> or that you would always get consistent data o
"Daniel P. Berrange" writes:
> On Tue, May 10, 2016 at 01:11:30PM +0100, Richard W.M. Jones wrote:
>> At no point did I say that it was safe to use libguestfs on live VMs
>> or that you would always get consistent data out.
>>
>> But the fact that it can fail is understood, the chance of failure
On Tue, 05/10 13:22, Daniel P. Berrange wrote:
> On Tue, May 10, 2016 at 01:11:30PM +0100, Richard W.M. Jones wrote:
> > At no point did I say that it was safe to use libguestfs on live VMs
> > or that you would always get consistent data out.
> >
> > But the fact that it can fail is understood, t
Am 10.05.2016 um 14:22 hat Daniel P. Berrange geschrieben:
> On Tue, May 10, 2016 at 01:11:30PM +0100, Richard W.M. Jones wrote:
> > At no point did I say that it was safe to use libguestfs on live VMs
> > or that you would always get consistent data out.
> >
> > But the fact that it can fail is u
On Tue, May 10, 2016 at 01:11:30PM +0100, Richard W.M. Jones wrote:
> At no point did I say that it was safe to use libguestfs on live VMs
> or that you would always get consistent data out.
>
> But the fact that it can fail is understood, the chance of failure is
> really tiny (it has literally o
At no point did I say that it was safe to use libguestfs on live VMs
or that you would always get consistent data out.
But the fact that it can fail is understood, the chance of failure is
really tiny (it has literally only happened twice that I've read
corrupted data, in years of daily use), and
Am 10.05.2016 um 13:46 hat Richard W.M. Jones geschrieben:
> On Tue, May 10, 2016 at 01:08:49PM +0200, Kevin Wolf wrote:
> > Are you saying that libguestfs only allows operations like df on live
> > images, but not e.g. copying files out of the VM?
> [...]
>
> virt-copy-out will let you copy out f
On Tue, May 10, 2016 at 01:08:49PM +0200, Kevin Wolf wrote:
> Are you saying that libguestfs only allows operations like df on live
> images, but not e.g. copying files out of the VM?
[...]
virt-copy-out will let you copy out files from a live VM.
There's no difference between "safe" and "unsafe"
Am 10.05.2016 um 12:29 hat Daniel P. Berrange geschrieben:
> On Tue, May 10, 2016 at 12:07:06PM +0200, Kevin Wolf wrote:
> > Am 10.05.2016 um 11:43 hat Daniel P. Berrange geschrieben:
> > > On Tue, May 10, 2016 at 11:35:14AM +0200, Kevin Wolf wrote:
> > > > Am 10.05.2016 um 11:23 hat Daniel P. Berr
Am 10.05.2016 um 12:16 hat Richard W.M. Jones geschrieben:
> On Tue, May 10, 2016 at 12:07:06PM +0200, Kevin Wolf wrote:
> > I'm surprised how low the standards seem to be when we're talking about
> > data integrity. If occasionally losing data is okay, the qemu block
> > layer could be quite a bit
On Tue, May 10, 2016 at 12:07:06PM +0200, Kevin Wolf wrote:
> Am 10.05.2016 um 11:43 hat Daniel P. Berrange geschrieben:
> > On Tue, May 10, 2016 at 11:35:14AM +0200, Kevin Wolf wrote:
> > > Am 10.05.2016 um 11:23 hat Daniel P. Berrange geschrieben:
> > > > On Tue, May 10, 2016 at 11:14:22AM +0200,
On Tue, May 10, 2016 at 12:07:06PM +0200, Kevin Wolf wrote:
> I'm surprised how low the standards seem to be when we're talking about
> data integrity. If occasionally losing data is okay, the qemu block
> layer could be quite a bit simpler.
I welcome this patch because it fixes a real data integr
Am 10.05.2016 um 11:43 hat Daniel P. Berrange geschrieben:
> On Tue, May 10, 2016 at 11:35:14AM +0200, Kevin Wolf wrote:
> > Am 10.05.2016 um 11:23 hat Daniel P. Berrange geschrieben:
> > > On Tue, May 10, 2016 at 11:14:22AM +0200, Kevin Wolf wrote:
> > > > Am 10.05.2016 um 10:50 hat Daniel P. Berr
On Tue, May 10, 2016 at 11:14:22AM +0200, Kevin Wolf wrote:
> Am 10.05.2016 um 10:50 hat Daniel P. Berrange geschrieben:
> > On Tue, May 10, 2016 at 09:43:04AM +0100, Richard W.M. Jones wrote:
> > > On Tue, May 10, 2016 at 09:14:26AM +0100, Richard W.M. Jones wrote:
> > > > However I didn't test t
On Tue, May 10, 2016 at 11:35:14AM +0200, Kevin Wolf wrote:
> Am 10.05.2016 um 11:23 hat Daniel P. Berrange geschrieben:
> > On Tue, May 10, 2016 at 11:14:22AM +0200, Kevin Wolf wrote:
> > > Am 10.05.2016 um 10:50 hat Daniel P. Berrange geschrieben:
> > > > On Tue, May 10, 2016 at 09:43:04AM +0100,
Am 10.05.2016 um 11:23 hat Daniel P. Berrange geschrieben:
> On Tue, May 10, 2016 at 11:14:22AM +0200, Kevin Wolf wrote:
> > Am 10.05.2016 um 10:50 hat Daniel P. Berrange geschrieben:
> > > On Tue, May 10, 2016 at 09:43:04AM +0100, Richard W.M. Jones wrote:
> > > > On Tue, May 10, 2016 at 09:14:26A
On Tue, May 10, 2016 at 11:14:22AM +0200, Kevin Wolf wrote:
> Am 10.05.2016 um 10:50 hat Daniel P. Berrange geschrieben:
> > On Tue, May 10, 2016 at 09:43:04AM +0100, Richard W.M. Jones wrote:
> > > On Tue, May 10, 2016 at 09:14:26AM +0100, Richard W.M. Jones wrote:
> > > > However I didn't test th
Am 10.05.2016 um 10:50 hat Daniel P. Berrange geschrieben:
> On Tue, May 10, 2016 at 09:43:04AM +0100, Richard W.M. Jones wrote:
> > On Tue, May 10, 2016 at 09:14:26AM +0100, Richard W.M. Jones wrote:
> > > However I didn't test the write-shareable case (the libvirt
> > > flag which should map to
On Tue, May 10, 2016 at 09:43:04AM +0100, Richard W.M. Jones wrote:
> On Tue, May 10, 2016 at 09:14:26AM +0100, Richard W.M. Jones wrote:
> > However I didn't test the write-shareable case (the libvirt
> > flag which should map to a shared lock -- is that right Dan?).
>
> To Dan (mainly): I think
On Tue, May 10, 2016 at 09:14:26AM +0100, Richard W.M. Jones wrote:
> However I didn't test the write-shareable case (the libvirt
> flag which should map to a shared lock -- is that right Dan?).
To Dan (mainly): I think setting the flag in libvirt only
sets cache=unsafe on the qemu drive (it may
On Tue, May 10, 2016 at 10:50:32AM +0800, Fam Zheng wrote:
> v4: Don't lock RO image. [Rich]
I applied this on top of HEAD and added some debugging messages to
block/raw-posix.c so I can see when files are being opened and locked,
and it does appear to do the right thing for read-only and
write-ex
v4: Don't lock RO image. [Rich]
v3: Highlight is handling of image locks during close(3) and bdrv_reopen(). A
number of new patches are added consequently.
Fam Zheng (27):
block: Add BDRV_O_NO_LOCK
qapi: Add lock-image in blockdev-add options
blockdev: Add and parse "lock-image" optio
27 matches
Mail list logo
