> > > FVD's novel uses of the reference count table reduces the metadata
update
> > > overhead down to literally zero during normal execution of a VM.
This gets
> > > the bests of QCOW2's reference count table but without its
oeverhead. In
> > > FVD, the reference count table is only updated whe
Am 14.03.2011 20:23, schrieb Chunqiang Tang:
>>> Here is a detailed description. Relevant to the discussion of
> snapshot,
>>> FVD uses a one-level lookup table and a refcount table. FVD’s
> one-level
>>> lookup table is very similar to QCOW2’s two-level lookup table, except
>
>>> that it is
> > Here is a detailed description. Relevant to the discussion of
snapshot,
> > FVD uses a one-level lookup table and a refcount table. FVD’s
one-level
> > lookup table is very similar to QCOW2’s two-level lookup table, except
> > that it is much smaller in FVD, and is preallocated and hence
Am 14.03.2011 17:32, schrieb Chunqiang Tang:
>>> FVD's novel uses of the reference count table reduces the metadata
> update
>>> overhead down to literally zero during normal execution of a VM. This
> gets
>>> the bests of QCOW2's reference count table but without its oeverhead.
> In
>>> FVD, th
> > FVD's novel uses of the reference count table reduces the metadata
update
> > overhead down to literally zero during normal execution of a VM. This
gets
> > the bests of QCOW2's reference count table but without its oeverhead.
In
> > FVD, the reference count table is only updated when creati
On 03/14/2011 10:03 AM, Kevin Wolf wrote:
The only problem with them is that they are metadata that must be
updated. However, I think we have discussed enough how to avoid the
greatest part of that cost.
Maybe I missed it, but in the WCE=0 mode, is it really possible to avoid
the writes for the
Am 14.03.2011 15:49, schrieb Anthony Liguori:
> On 03/14/2011 09:21 AM, Kevin Wolf wrote:
>> Am 14.03.2011 15:02, schrieb Anthony Liguori:
>>> On 03/14/2011 08:53 AM, Chunqiang Tang wrote:
> No, because the copy-on-write is another layer on top of the snapshot
> and AFAICT, they don't persi
On Mon, Mar 14, 2011 at 3:04 PM, Chunqiang Tang wrote:
>> >> The file system can keep a lot of these things around pretty easily
> but
>> >> with your proposal, it seems like there can only be one. If you
> support
>> >> many of them, I think you'll degenerate to something as complex as a
>> >> r
Am 14.03.2011 15:47, schrieb Anthony Liguori:
> On 03/14/2011 09:15 AM, Kevin Wolf wrote:
>>> The file system can keep a lot of these things around pretty easily but
>>> with your proposal, it seems like there can only be one. If you support
>>> many of them, I think you'll degenerate to something
On Mon, Mar 14, 2011 at 2:49 PM, Anthony Liguori wrote:
> On 03/14/2011 09:21 AM, Kevin Wolf wrote:
>>
>> Am 14.03.2011 15:02, schrieb Anthony Liguori:
>>>
>>> On 03/14/2011 08:53 AM, Chunqiang Tang wrote:
>
> No, because the copy-on-write is another layer on top of the snapshot
> and
> >> The file system can keep a lot of these things around pretty easily
but
> >> with your proposal, it seems like there can only be one. If you
support
> >> many of them, I think you'll degenerate to something as complex as a
> >> reference count table.
> > IIUC, he already uses a refcount tab
On Mon, Mar 14, 2011 at 2:25 PM, Chunqiang Tang wrote:
>> IIUC, he already uses a refcount table. Actually, I think that a
>> refcount table is a requirement to provide the interesting properties
>> that internal snapshots have (see my other mail).
>>
>> Refcount tables aren't a very complex thing
On 03/14/2011 09:21 AM, Kevin Wolf wrote:
Am 14.03.2011 15:02, schrieb Anthony Liguori:
On 03/14/2011 08:53 AM, Chunqiang Tang wrote:
No, because the copy-on-write is another layer on top of the snapshot
and AFAICT, they don't persist when moving between snapshots.
The equivalent for external
> On Mon, Mar 14, 2011 at 1:53 PM, Chunqiang Tang
wrote:
> > Therefore, during normal execution of a
> > VM, images with snapshots are as fast as images without snapshot.
>
> Hang on, an image with a snapshot still needs to do copy-on-write,
> just like backing files. The cost of copy-on-write
On 03/14/2011 09:15 AM, Kevin Wolf wrote:
The file system can keep a lot of these things around pretty easily but
with your proposal, it seems like there can only be one. If you support
many of them, I think you'll degenerate to something as complex as a
reference count table.
IIUC, he already
Am 14.03.2011 15:25, schrieb Chunqiang Tang:
>> IIUC, he already uses a refcount table. Actually, I think that a
>> refcount table is a requirement to provide the interesting properties
>> that internal snapshots have (see my other mail).
>>
>> Refcount tables aren't a very complex thing either. In
> > Your use of "current-state" is confusing me because AFAICT,
> > current-state is just semantically another snapshot.
> >
> > It's writable because it has no children. You only keep around one
> > writable snapshot and to make another snapshot writable, you have to
> > discard the former.
>
On Mon, Mar 14, 2011 at 1:53 PM, Chunqiang Tang wrote:
> Therefore, during normal execution of a
> VM, images with snapshots are as fast as images without snapshot.
Hang on, an image with a snapshot still needs to do copy-on-write,
just like backing files. The cost of copy-on-write is reading da
Am 14.03.2011 15:02, schrieb Anthony Liguori:
> On 03/14/2011 08:53 AM, Chunqiang Tang wrote:
>>> No, because the copy-on-write is another layer on top of the snapshot
>>> and AFAICT, they don't persist when moving between snapshots.
>>>
>>> The equivalent for external snapshots would be:
>>>
>>> b
> IIUC, he already uses a refcount table. Actually, I think that a
> refcount table is a requirement to provide the interesting properties
> that internal snapshots have (see my other mail).
>
> Refcount tables aren't a very complex thing either. In fact, it makes a
> format much simpler to have o
Am 14.03.2011 14:22, schrieb Anthony Liguori:
> On 03/13/2011 09:28 PM, Chunqiang Tang wrote:
In short, FVD's internal snapshot achieves the ideal properties of
>> G1-G6,
by 1) using the reference count table to only track "static"
>> snapshots, 2)
not keeping the reference count tab
On 03/14/2011 08:53 AM, Chunqiang Tang wrote:
No, because the copy-on-write is another layer on top of the snapshot
and AFAICT, they don't persist when moving between snapshots.
The equivalent for external snapshots would be:
base0<- base1<- base2<- image
And then if I wanted to move to base1
> No, because the copy-on-write is another layer on top of the snapshot
> and AFAICT, they don't persist when moving between snapshots.
>
> The equivalent for external snapshots would be:
>
> base0 <- base1 <- base2 <- image
>
> And then if I wanted to move to base1 without destroying base2 and
On 03/13/2011 09:28 PM, Chunqiang Tang wrote:
In short, FVD's internal snapshot achieves the ideal properties of
G1-G6,
by 1) using the reference count table to only track "static"
snapshots, 2)
not keeping the reference count table in memory, 3) not updating the
on-disk "static" reference co
Am 13.03.2011 06:51, schrieb Chunqiang Tang:
> After the heated debate, I thought more about the right approach of
> implementing snapshot, and it becomes clear to me that there are major
> limitations with both VMDK's external snapshot approach (which stores each
> snapshot as a separate CoW fi
> > In short, FVD's internal snapshot achieves the ideal properties of
G1-G6,
> > by 1) using the reference count table to only track "static"
snapshots, 2)
> > not keeping the reference count table in memory, 3) not updating the
> > on-disk "static" reference count table when the VM runs, and 4)
On 03/12/2011 11:51 PM, Chunqiang Tang wrote:
In short, FVD's internal snapshot achieves the ideal properties of G1-G6,
by 1) using the reference count table to only track "static" snapshots, 2)
not keeping the reference count table in memory, 3) not updating the
on-disk "static" reference count
> It seems that there is great interest in QCOW2's
> internal snapshot feature. If we really want to do that, the right
solution is
> to follow VMDK's approach of storing each snapshot as a separate COW
file (see
> http://www.vmware.com/app/vmdk/?src=vmdk ), rather than using the
reference
> c
On Fri, Feb 25, 2011 at 11:20 AM, Pavel Dovgaluk
wrote:
>
>> On 02/23/2011 05:50 PM, Anthony Liguori wrote:
>> >> I still don't see. What would you do with thousands of checkpoints?
>> >
>> >
>> > For reverse debugging, if you store checkpoints at a rate of save,
>> > every 10ms, and then degrade
> On 02/23/2011 05:50 PM, Anthony Liguori wrote:
> >> I still don't see. What would you do with thousands of checkpoints?
> >
> >
> > For reverse debugging, if you store checkpoints at a rate of save,
> > every 10ms, and then degrade to storing every 100ms after 1 second,
> > etc. you'll have qui
Am 23.02.2011 17:04, schrieb Anthony Liguori:
> On 02/23/2011 10:03 AM, Avi Kivity wrote:
>> On 02/23/2011 05:50 PM, Anthony Liguori wrote:
I still don't see. What would you do with thousands of checkpoints?
>>>
>>>
>>> For reverse debugging, if you store checkpoints at a rate of save,
>>> e
On 02/23/2011 05:50 PM, Anthony Liguori wrote:
I still don't see. What would you do with thousands of checkpoints?
For reverse debugging, if you store checkpoints at a rate of save,
every 10ms, and then degrade to storing every 100ms after 1 second,
etc. you'll have quite a large number of
On 02/23/2011 10:03 AM, Avi Kivity wrote:
On 02/23/2011 05:50 PM, Anthony Liguori wrote:
I still don't see. What would you do with thousands of checkpoints?
For reverse debugging, if you store checkpoints at a rate of save,
every 10ms, and then degrade to storing every 100ms after 1 second,
On 02/23/2011 05:52 PM, Anthony Liguori wrote:
I still don't see. What would you do with thousands of checkpoints?
Er, hit send to quickly.
HPC is a big space where checkpointing is actually useful. An HPC
workload may take weeks to run to completion. If something fails
during the run, i
On Wed, Feb 23, 2011 at 09:52:02AM -0600, Anthony Liguori wrote:
> On 02/23/2011 09:37 AM, Avi Kivity wrote:
> >On 02/23/2011 05:31 PM, Anthony Liguori wrote:
> >>>
> what about snapshots? Are we okay having a feature in a
> prominent format that isn't going to meet user's
> expectatio
On 02/23/2011 05:47 PM, Anthony Liguori wrote:
I don't see how that works, since the memory image is duplicated for
each snapshot. So thousands of snapshots = terabytes of storage, and
hours of creating the snapshots.
Fabrice wanted to use CoW to as a mechanism to deduplicate the memory
con
Am 23.02.2011 16:29, schrieb Anthony Liguori:
> On 02/23/2011 08:38 AM, Kevin Wolf wrote:
>> Am 23.02.2011 15:23, schrieb Anthony Liguori:
>>
>>> On 02/23/2011 07:43 AM, Avi Kivity wrote:
>>>
On 02/22/2011 10:56 AM, Kevin Wolf wrote:
> *sigh*
>
> It starts to
On 02/23/2011 09:37 AM, Avi Kivity wrote:
On 02/23/2011 05:31 PM, Anthony Liguori wrote:
what about snapshots? Are we okay having a feature in a prominent
format that isn't going to meet user's expectations?
Is there any hope that an image with 1000, 1000, or 1 snapshots
is going to ha
On 02/23/2011 09:37 AM, Avi Kivity wrote:
On 02/23/2011 05:31 PM, Anthony Liguori wrote:
what about snapshots? Are we okay having a feature in a prominent
format that isn't going to meet user's expectations?
Is there any hope that an image with 1000, 1000, or 1 snapshots
is going to ha
On 02/23/2011 09:36 AM, Avi Kivity wrote:
On 02/23/2011 05:29 PM, Anthony Liguori wrote:
existed, what about snapshots? Are we okay having a feature in a
prominent format that isn't going to meet user's expectations?
Is there any hope that an image with 1000, 1000, or 1 snapshots is
goin
On 02/23/2011 05:31 PM, Anthony Liguori wrote:
what about snapshots? Are we okay having a feature in a prominent
format that isn't going to meet user's expectations?
Is there any hope that an image with 1000, 1000, or 1 snapshots
is going to have even reasonable performance in qcow2?
On 02/23/2011 05:33 PM, Daniel P. Berrange wrote:
On Wed, Feb 23, 2011 at 05:23:33PM +0200, Avi Kivity wrote:
> On 02/23/2011 04:23 PM, Anthony Liguori wrote:
> >On 02/23/2011 07:43 AM, Avi Kivity wrote:
> >>On 02/22/2011 10:56 AM, Kevin Wolf wrote:
> >>>*sigh*
> >>>
> >>>It starts to get a
On 02/23/2011 05:29 PM, Anthony Liguori wrote:
existed, what about snapshots? Are we okay having a feature in a
prominent format that isn't going to meet user's expectations?
Is there any hope that an image with 1000, 1000, or 1 snapshots is
going to have even reasonable performance in qc
On 02/23/2011 09:23 AM, Avi Kivity wrote:
On 02/23/2011 04:23 PM, Anthony Liguori wrote:
On 02/23/2011 07:43 AM, Avi Kivity wrote:
On 02/22/2011 10:56 AM, Kevin Wolf wrote:
*sigh*
It starts to get annoying, but if you really insist, I can repeat it
once more: These features that you don't nee
On Wed, Feb 23, 2011 at 05:23:33PM +0200, Avi Kivity wrote:
> On 02/23/2011 04:23 PM, Anthony Liguori wrote:
> >On 02/23/2011 07:43 AM, Avi Kivity wrote:
> >>On 02/22/2011 10:56 AM, Kevin Wolf wrote:
> >>>*sigh*
> >>>
> >>>It starts to get annoying, but if you really insist, I can repeat it
> >>>on
On 02/23/2011 08:38 AM, Kevin Wolf wrote:
Am 23.02.2011 15:23, schrieb Anthony Liguori:
On 02/23/2011 07:43 AM, Avi Kivity wrote:
On 02/22/2011 10:56 AM, Kevin Wolf wrote:
*sigh*
It starts to get annoying, but if you really insist, I can repeat it
once more: These features t
On 02/23/2011 04:23 PM, Anthony Liguori wrote:
On 02/23/2011 07:43 AM, Avi Kivity wrote:
On 02/22/2011 10:56 AM, Kevin Wolf wrote:
*sigh*
It starts to get annoying, but if you really insist, I can repeat it
once more: These features that you don't need (this is the correct
description for what
Am 23.02.2011 15:21, schrieb Anthony Liguori:
> On 02/23/2011 03:13 AM, Kevin Wolf wrote:
>> Am 22.02.2011 19:18, schrieb Anthony Liguori:
>>
>>> On 02/22/2011 10:15 AM, Kevin Wolf wrote:
>>>
Am 22.02.2011 16:57, schrieb Anthony Liguori:
> On 02/22/2011 02:56 AM
Am 23.02.2011 15:23, schrieb Anthony Liguori:
> On 02/23/2011 07:43 AM, Avi Kivity wrote:
>> On 02/22/2011 10:56 AM, Kevin Wolf wrote:
>>> *sigh*
>>>
>>> It starts to get annoying, but if you really insist, I can repeat it
>>> once more: These features that you don't need (this is the correct
>>> d
On 02/23/2011 03:13 AM, Kevin Wolf wrote:
Am 22.02.2011 19:18, schrieb Anthony Liguori:
On 02/22/2011 10:15 AM, Kevin Wolf wrote:
Am 22.02.2011 16:57, schrieb Anthony Liguori:
On 02/22/2011 02:56 AM, Kevin Wolf wrote:
*sigh*
It starts to get annoying, but if you
On 02/23/2011 07:43 AM, Avi Kivity wrote:
On 02/22/2011 10:56 AM, Kevin Wolf wrote:
*sigh*
It starts to get annoying, but if you really insist, I can repeat it
once more: These features that you don't need (this is the correct
description for what you call "misfeatures") _are_ implemented in a
On 02/22/2011 10:56 AM, Kevin Wolf wrote:
*sigh*
It starts to get annoying, but if you really insist, I can repeat it
once more: These features that you don't need (this is the correct
description for what you call "misfeatures") _are_ implemented in a way
that they don't impact the "normal" cas
Chunqiang Tang writes:
[...]
> Now let’s talk about features. It seems that there is great interest in
> QCOW2’ internal snapshot feature. If we really want to do that, the right
Great interest? Its use cases are demo, debugging, testing and such.
Kind of useful for developers, but I wouldn't
Am 22.02.2011 19:18, schrieb Anthony Liguori:
> On 02/22/2011 10:15 AM, Kevin Wolf wrote:
>> Am 22.02.2011 16:57, schrieb Anthony Liguori:
>>
>>> On 02/22/2011 02:56 AM, Kevin Wolf wrote:
>>>
*sigh*
It starts to get annoying, but if you really insist, I can repeat it
o
> In any case, the next step is to get down to specifics. Here is the
> page with the current QCOW3 roadmap:
>
> http://wiki.qemu.org/Qcow3_Roadmap
>
> Please raise concrete requirements or features so they can be
> discussed and captured.
Now it turns into a more productive discussion, but it s
On 02/22/2011 10:15 AM, Kevin Wolf wrote:
Am 22.02.2011 16:57, schrieb Anthony Liguori:
On 02/22/2011 02:56 AM, Kevin Wolf wrote:
*sigh*
It starts to get annoying, but if you really insist, I can repeat it
once more: These features that you don't need (this is the correct
description
Am 22.02.2011 16:57, schrieb Anthony Liguori:
> On 02/22/2011 02:56 AM, Kevin Wolf wrote:
>>
>> *sigh*
>>
>> It starts to get annoying, but if you really insist, I can repeat it
>> once more: These features that you don't need (this is the correct
>> description for what you call "misfeatures") _ar
On 02/22/2011 02:56 AM, Kevin Wolf wrote:
*sigh*
It starts to get annoying, but if you really insist, I can repeat it
once more: These features that you don't need (this is the correct
description for what you call "misfeatures") _are_ implemented in a way
that they don't impact the "normal" ca
Kevin Wolf writes:
> Am 22.02.2011 09:37, schrieb Markus Armbruster:
>> Anthony Liguori writes:
>>
>>> On 02/18/2011 03:57 AM, Kevin Wolf wrote:
Am 18.02.2011 10:12, schrieb Markus Armbruster:
> Kevin Wolf writes:
>
>
>> Am 15.02.2011 20:45, schrieb Chunqian
Am 22.02.2011 09:37, schrieb Markus Armbruster:
> Anthony Liguori writes:
>
>> On 02/18/2011 03:57 AM, Kevin Wolf wrote:
>>> Am 18.02.2011 10:12, schrieb Markus Armbruster:
>>>
Kevin Wolf writes:
> Am 15.02.2011 20:45, schrieb Chunqiang Tang:
>
>>> Ch
Aurelien Jarno writes:
[...]
> I agree that the best would be to have a single format, and it's
> probably a goal to have. That said, what is most important to my view is
> having one or two formats which together have _all_ the features (and
> here I consider speed as a feature) of the existing
Anthony Liguori writes:
> On 02/18/2011 03:57 AM, Kevin Wolf wrote:
>> Am 18.02.2011 10:12, schrieb Markus Armbruster:
>>
>>> Kevin Wolf writes:
>>>
>>>
Am 15.02.2011 20:45, schrieb Chunqiang Tang:
>> Chunqiang Tang/Watson/IBM wrote on 01/28/2011 05:13:27 PM:
Am 21.02.2011 16:16, schrieb Anthony Liguori:
> On 02/21/2011 08:10 AM, Kevin Wolf wrote:
>> Am 21.02.2011 14:44, schrieb Stefan Hajnoczi:
>>
>>> On Mon, Feb 21, 2011 at 8:59 AM, Kevin Wolf wrote:
>>>
In fact, the only area where qcow2 in performs really bad in 0.14 is
cache=wr
On 02/21/2011 08:10 AM, Kevin Wolf wrote:
Am 21.02.2011 14:44, schrieb Stefan Hajnoczi:
On Mon, Feb 21, 2011 at 8:59 AM, Kevin Wolf wrote:
In fact, the only area where qcow2 in performs really bad in 0.14 is
cache=writethrough (which unfortunately is the default...). With
cache=none
Am 21.02.2011 14:44, schrieb Stefan Hajnoczi:
> On Mon, Feb 21, 2011 at 8:59 AM, Kevin Wolf wrote:
>> In fact, the only area where qcow2 in performs really bad in 0.14 is
>> cache=writethrough (which unfortunately is the default...). With
>> cache=none it's easy to find scenarios where it provides
On Mon, Feb 21, 2011 at 8:59 AM, Kevin Wolf wrote:
> In fact, the only area where qcow2 in performs really bad in 0.14 is
> cache=writethrough (which unfortunately is the default...). With
> cache=none it's easy to find scenarios where it provides higher
> throughput than QED.
Yeah, I'm tempted t
Am 20.02.2011 23:13, schrieb Aurelien Jarno:
> On Fri, Feb 18, 2011 at 10:57:05AM +0100, Kevin Wolf wrote:
>> Am 18.02.2011 10:12, schrieb Markus Armbruster:
>>> Kevin Wolf writes:
>>>
Am 15.02.2011 20:45, schrieb Chunqiang Tang:
>> Chunqiang Tang/Watson/IBM wrote on 01/28/2011 05:13:27 P
On Fri, Feb 18, 2011 at 10:57:05AM +0100, Kevin Wolf wrote:
> Am 18.02.2011 10:12, schrieb Markus Armbruster:
> > Kevin Wolf writes:
> >
> >> Am 15.02.2011 20:45, schrieb Chunqiang Tang:
> Chunqiang Tang/Watson/IBM wrote on 01/28/2011 05:13:27 PM:
> As you requested, I set up a wiki pag
On Fri, Feb 18, 2011 at 7:11 PM, Kevin Wolf wrote:
> Am 18.02.2011 18:43, schrieb Stefan Weil:
>> Is maintaining an additional file format really so much work?
>> I have only some personal experience with vdi.c, and there maintainance
>> was largely caused by interface changes and done by Kevin.
>
Am 18.02.2011 21:50, schrieb Anthony Liguori:
> On 02/18/2011 02:49 PM, Kevin Wolf wrote:
>> Am 18.02.2011 20:47, schrieb Anthony Liguori:
>>
>>> On 02/18/2011 01:11 PM, Kevin Wolf wrote:
>>>
> A new file format like fvd would be a challenge for the existing ones.
> Declare its su
On 02/18/2011 02:49 PM, Kevin Wolf wrote:
Am 18.02.2011 20:47, schrieb Anthony Liguori:
On 02/18/2011 01:11 PM, Kevin Wolf wrote:
A new file format like fvd would be a challenge for the existing ones.
Declare its support as unsupported or experimental, but let users
decide which one i
Am 18.02.2011 20:47, schrieb Anthony Liguori:
> On 02/18/2011 01:11 PM, Kevin Wolf wrote:
>>> A new file format like fvd would be a challenge for the existing ones.
>>> Declare its support as unsupported or experimental, but let users
>>> decide which one is best suited to their needs!
>>>
>>
On 02/18/2011 11:43 AM, Stefan Weil wrote:
Is maintaining an additional file format really so much work?
I have only some personal experience with vdi.c, and there maintainance
was largely caused by interface changes and done by Kevin.
Hopefully interfaces will stabilize, so changes will become
On 02/18/2011 01:11 PM, Kevin Wolf wrote:
A new file format like fvd would be a challenge for the existing ones.
Declare its support as unsupported or experimental, but let users
decide which one is best suited to their needs!
Basically this is what we did for QED. In hindsight I consider
Am 18.02.2011 18:43, schrieb Stefan Weil:
> Am 18.02.2011 10:57, schrieb Kevin Wolf:
>> Am 18.02.2011 10:12, schrieb Markus Armbruster:
>>> Kevin Wolf writes:
>>>
Yet another file format with yet another implementation is definitely
not what we need. We should probably take some of the i
Am 18.02.2011 10:57, schrieb Kevin Wolf:
Am 18.02.2011 10:12, schrieb Markus Armbruster:
Kevin Wolf writes:
Yet another file format with yet another implementation is definitely
not what we need. We should probably take some of the ideas in FVD and
consider them for qcow3.
Got an assumption
On 02/18/2011 03:57 AM, Kevin Wolf wrote:
Am 18.02.2011 10:12, schrieb Markus Armbruster:
Kevin Wolf writes:
Am 15.02.2011 20:45, schrieb Chunqiang Tang:
Chunqiang Tang/Watson/IBM wrote on 01/28/2011 05:13:27 PM:
As you requested, I set up a wiki page for FVD at
Am 18.02.2011 10:12, schrieb Markus Armbruster:
> Kevin Wolf writes:
>
>> Am 15.02.2011 20:45, schrieb Chunqiang Tang:
Chunqiang Tang/Watson/IBM wrote on 01/28/2011 05:13:27 PM:
As you requested, I set up a wiki page for FVD at
>>> http://wiki.qemu.org/Features/FVD
. It includes a
78 matches
Mail list logo
