Am 06.04.2015 um 17:37 hat Michael Tokarev geschrieben:
> 02.04.2015 16:19, Kevin Wolf wrote:
> > Am 02.04.2015 um 14:04 hat Michael Tokarev geschrieben:
> >> 02.04.2015 14:24, Kevin Wolf wrote:
> >> []
> But overall, I think qemu-system should not modify backing
> file name in this case.
Am 03.04.2015 um 05:59 hat Jeff Cody geschrieben:
> On Thu, Apr 02, 2015 at 01:24:02PM +0200, Kevin Wolf wrote:
> > Am 02.04.2015 um 12:58 hat Michael Tokarev geschrieben:
> > > When performing commit, does qemu mark the areas in the
> > > overlay file as free after writing contents to the backing
02.04.2015 16:19, Kevin Wolf wrote:
> Am 02.04.2015 um 14:04 hat Michael Tokarev geschrieben:
>> 02.04.2015 14:24, Kevin Wolf wrote:
>> []
But overall, I think qemu-system should not modify backing
file name in this case.
>>>
>>> So you would leave the backing file with the data that you
On Fri, Apr 03, 2015 at 01:49:01PM -0600, Eric Blake wrote:
> On 04/02/2015 10:28 PM, Jeff Cody wrote:
>
> >>
> >> Basically, once a commit crosses more than one file, all intermediate
> >> files are useless and might as well be discarded.
>
> That's if you do a job-complete operation. But if yo
On 04/02/2015 10:28 PM, Jeff Cody wrote:
>>
>> Basically, once a commit crosses more than one file, all intermediate
>> files are useless and might as well be discarded.
That's if you do a job-complete operation. But if you do a job-abort
operation, the chain is left intact. What we should prob
On Thu, Apr 02, 2015 at 07:07:23AM -0600, Eric Blake wrote:
> On 04/02/2015 06:04 AM, Michael Tokarev wrote:
> > 02.04.2015 14:24, Kevin Wolf wrote:
> > []
> >>> But overall, I think qemu-system should not modify backing
> >>> file name in this case.
> >>
> >> So you would leave the backing file wi
On Thu, Apr 02, 2015 at 01:24:02PM +0200, Kevin Wolf wrote:
> Am 02.04.2015 um 12:58 hat Michael Tokarev geschrieben:
> > 01.04.2015 15:34, Kevin Wolf wrote:
> > []
> > > Overriding the backing file should work like this:
> > >
> > > -drive file=...,backing.file.filename=/dev/fdset/2
> >
> >
Am 02.04.2015 um 14:04 hat Michael Tokarev geschrieben:
> 02.04.2015 14:24, Kevin Wolf wrote:
> []
> >> But overall, I think qemu-system should not modify backing
> >> file name in this case.
> >
> > So you would leave the backing file with the data that you just
> > committed down one level in yo
On 04/02/2015 06:04 AM, Michael Tokarev wrote:
> 02.04.2015 14:24, Kevin Wolf wrote:
> []
>>> But overall, I think qemu-system should not modify backing
>>> file name in this case.
>>
>> So you would leave the backing file with the data that you just
>> committed down one level in your backing file
02.04.2015 14:24, Kevin Wolf wrote:
[]
>> But overall, I think qemu-system should not modify backing
>> file name in this case.
>
> So you would leave the backing file with the data that you just
> committed down one level in your backing file chain? Wouldn't that
> defeat the whole purpose of com
Am 02.04.2015 um 12:58 hat Michael Tokarev geschrieben:
> 01.04.2015 15:34, Kevin Wolf wrote:
> []
> > Overriding the backing file should work like this:
> >
> > -drive file=...,backing.file.filename=/dev/fdset/2
>
> Oh-ok, this works. Sort of.
>
> Because after performing commit (is there
01.04.2015 15:34, Kevin Wolf wrote:
[]
> Overriding the backing file should work like this:
>
> -drive file=...,backing.file.filename=/dev/fdset/2
Oh-ok, this works. Sort of.
Because after performing commit (is there a difference between
commit hmp command and block-commit qmp command? I u
Am 01.04.2015 um 11:54 hat Michael Tokarev geschrieben:
> 01.04.2015 12:26, Michael Tokarev пишет:
> > 30.03.2015 18:36, Kevin Wolf wrote:
> >> Am 27.03.2015 um 18:12 hat Eric Blake geschrieben:
> >>> On 03/27/2015 09:36 AM, Michael Tokarev wrote:
> Wonder how to specify cache mode, or should
01.04.2015 12:26, Michael Tokarev пишет:
> 30.03.2015 18:36, Kevin Wolf wrote:
>> Am 27.03.2015 um 18:12 hat Eric Blake geschrieben:
>>> On 03/27/2015 09:36 AM, Michael Tokarev wrote:
Wonder how to specify cache mode, or should I open these with proper
O_DIRECT/O_SYNC/whatever? It looks
30.03.2015 18:36, Kevin Wolf wrote:
> Am 27.03.2015 um 18:12 hat Eric Blake geschrieben:
>> On 03/27/2015 09:36 AM, Michael Tokarev wrote:
>>> Wonder how to specify cache mode, or should I open these with proper
>>> O_DIRECT/O_SYNC/whatever? It looks like it's possible to change O_DIRECT
>>> at ru
Am 27.03.2015 um 18:12 hat Eric Blake geschrieben:
> On 03/27/2015 09:36 AM, Michael Tokarev wrote:
> > Wonder how to specify cache mode, or should I open these with proper
> > O_DIRECT/O_SYNC/whatever? It looks like it's possible to change O_DIRECT
> > at runtime but not O_SYNC.
> >
> > And the
On 03/27/2015 09:36 AM, Michael Tokarev wrote:
>> It is already possible to open a file read-write on the command line, by
>> using -add-fd twice to put both a read-only and a read-write fd handle
>> to the same file in a single set N, then using -drive options to specify
>> /dev/fdset/N rather tha
27.03.2015 17:49, Eric Blake wrote:
> On 03/27/2015 03:07 AM, Michael Tokarev wrote:
>> Hello.
>>
>> I tried to experiment with block-commit command, which propagates
>> changes accumulated in an overlay (qcow2) block image file back to
>> the base image file.
>>
>> And immediately faced a problem.
On 03/27/2015 03:07 AM, Michael Tokarev wrote:
> Hello.
>
> I tried to experiment with block-commit command, which propagates
> changes accumulated in an overlay (qcow2) block image file back to
> the base image file.
>
> And immediately faced a problem. All my VMs are run chrooted into
> an emp
Hello.
I tried to experiment with block-commit command, which propagates
changes accumulated in an overlay (qcow2) block image file back to
the base image file.
And immediately faced a problem. All my VMs are run chrooted into
an empty dir and with low-priv user (using -runsa and -chroot options
20 matches
Mail list logo
