[Qemu-devel] GSoC - QCOW2 <-> QED image converter

[Qemu-devel] GSoC - QCOW2 <-> QED image converter

[Lyu Mitnick]

[-- Attachment #1: Type: text/plain, Size: 457 bytes --]

Hello all,

Looking at QEMU'w wiki I saw the "QCOW2 <- > QED image converter", that I
am
also interested to work as student and apply for GSoC 2011. I have study
the
specifications of the two images and have some idea about
implementation. There
is someone already working on this project?? I also want to apply for
"Improved
image format compatibility". Could I merge the two idea into one application
or I should
apply separately??

Thanks a lot

Mitnick

[-- Attachment #2: Type: text/html, Size: 619 bytes --]

Re: [Qemu-devel] GSoC - QCOW2 <-> QED image converter

[Stefan Hajnoczi]

On Mon, Apr 4, 2011 at 7:56 PM, Lyu Mitnick <mitnick.lyu@gmail.com> wrote:
> Hello all,
> Looking at QEMU'w wiki I saw the "QCOW2 <- > QED image converter", that I
> am
> also interested to work as student and apply for GSoC 2011. I have study
> the
> specifications of the two images and have some idea about
> implementation. There
> is someone already working on this project?? I also want to apply for
> "Improved
> image format compatibility". Could I merge the two idea into one application
> or I should
> apply separately??

Other students have expressed their interest too, but that is normal
for GSoC project ideas.

Please just note on your application that you'd be interested in doing
QCOW2<->QED, there's no need to do a separate application in this
case.  The mentors are the same for both QCOW2<->QED and image format
updates.  The area of these two projects is similar, and we select the
most talented students rather than the best application forms.  I am
confident the selected student(s) would be capable of tackling either
project.

If you want to diversify your GSoC applications to increase your
chance of getting a place, then I suggest applying at a different
organization in addition to QEMU.org.  That way you are not subject to
the QEMU.org slot allocation.

Stefan

Re: [Qemu-devel] GSoC - QCOW2 <-> QED image converter

[Lyu Mitnick]

[-- Attachment #1: Type: text/plain, Size: 1831 bytes --]

Hello Stefan, Kevin

I don't want to diversify my GSoC applications. I thought I should do my
best of
supporting fully VHD and add asynchronous io into block/vpc.c via
coroutines. I
noticed that there is "splitting hard disk images" feature in VHD
specification. I
have take a look of block/raw-win32.c and guess there isn't this feature in
block/vpc.c.
I am wondering whether what I learned is right??

2011/4/5 Stefan Hajnoczi <stefanha@gmail.com>

> On Mon, Apr 4, 2011 at 7:56 PM, Lyu Mitnick <mitnick.lyu@gmail.com> wrote:
> > Hello all,
> > Looking at QEMU'w wiki I saw the "QCOW2 <- > QED image converter", that I
> > am
> > also interested to work as student and apply for GSoC 2011. I have study
> > the
> > specifications of the two images and have some idea about
> > implementation. There
> > is someone already working on this project?? I also want to apply for
> > "Improved
> > image format compatibility". Could I merge the two idea into one
> application
> > or I should
> > apply separately??
>
> Other students have expressed their interest too, but that is normal
> for GSoC project ideas.
>
> Please just note on your application that you'd be interested in doing
> QCOW2<->QED, there's no need to do a separate application in this
> case.  The mentors are the same for both QCOW2<->QED and image format
> updates.  The area of these two projects is similar, and we select the
> most talented students rather than the best application forms.  I am
> confident the selected student(s) would be capable of tackling either
> project.
>
> If you want to diversify your GSoC applications to increase your
> chance of getting a place, then I suggest applying at a different
> organization in addition to QEMU.org.  That way you are not subject to
> the QEMU.org slot allocation.
>
> Stefan
>


Thanks a lot

Mitnick

[-- Attachment #2: Type: text/html, Size: 2523 bytes --]

Re: [Qemu-devel] GSoC - QCOW2 <-> QED image converter

[Stefan Hajnoczi]

On Tue, Apr 5, 2011 at 7:03 PM, Lyu Mitnick <mitnick.lyu@gmail.com> wrote:
> Hello Stefan, Kevin
> I don't want to diversify my GSoC applications. I thought I should do my
> best of
> supporting fully VHD and add asynchronous io into block/vpc.c via
> coroutines. I
> noticed that there is "splitting hard disk images" feature in VHD
> specification. I
> have take a look of block/raw-win32.c and guess there isn't this feature in
> block/vpc.c.
> I am wondering whether what I learned is right??

Yes, split images are not supported by block/vpc.c.

Stefan

Re: [Qemu-devel] GSoC - QCOW2 <-> QED image converter

[Lyu Mitnick]

[-- Attachment #1: Type: text/plain, Size: 1327 bytes --]

Hello Stefan,

"splitting hard disk images" feature depends on win32 file system. I am
wondering
whether it is suitable to implement in raw-win32.c?? My idea is as follows:
(1) adding an array to store file descriptor related in BDRVRawState
(2) detect all splitted files in raw_open(). ie. consider
files filename.vhd, filename.v01,
     filename.v02 ... . and construct the table to convert from sector_num
to splitted file
     and offset (store in BDRVRawState, too).
(3) use table constructed in step2 to read, write and flush
(4) close all opened splitted files in raw_close()

Would you mind to give some advice about the solution I take in this
problem??

2011/4/6 Stefan Hajnoczi <stefanha@gmail.com>

> On Tue, Apr 5, 2011 at 7:03 PM, Lyu Mitnick <mitnick.lyu@gmail.com> wrote:
> > Hello Stefan, Kevin
> > I don't want to diversify my GSoC applications. I thought I should do my
> > best of
> > supporting fully VHD and add asynchronous io into block/vpc.c via
> > coroutines. I
> > noticed that there is "splitting hard disk images" feature in VHD
> > specification. I
> > have take a look of block/raw-win32.c and guess there isn't this feature
> in
> > block/vpc.c.
> > I am wondering whether what I learned is right??
>
> Yes, split images are not supported by block/vpc.c.
>
> Stefan
>


Thanks so much

Mitnick

[-- Attachment #2: Type: text/html, Size: 1963 bytes --]

Re: [Qemu-devel] GSoC - QCOW2 <-> QED image converter

[Stefan Hajnoczi]

On Wed, Apr 6, 2011 at 12:13 PM, Lyu Mitnick <mitnick.lyu@gmail.com> wrote:
> Hello Stefan,
> "splitting hard disk images" feature depends on win32 file system. I am
> wondering
> whether it is suitable to implement in raw-win32.c??

No, raw-win32.c is not the right place to do this.

If I create a split file with VirtualPC under Windows 2000 and then
transfer it to my Linux host then QEMU should still be able to read
the file.  This feature is not tied to the host platform or file
system.

It is block/vpc.c that needs to handle this.  The first file can be
opened as normal because it has the header.  The code can detect that
the image file is split and simply open additional files as necessary.

Stefan

Re: [Qemu-devel] GSoC - QCOW2 <-> QED image converter

[Christoph Hellwig]

On Wed, Apr 06, 2011 at 07:41:37AM +0100, Stefan Hajnoczi wrote:
> Yes, split images are not supported by block/vpc.c.

I'm working on that feature for vmdk right now, which is quite
interesting as vmdk really is two different format both claiming
to be vmdk, of which one is simply a text file telling how other
vmdk images are glued together.

Re: [Qemu-devel] GSoC - QCOW2 <-> QED image converter

[Kevin Wolf]

Am 06.04.2011 17:06, schrieb Christoph Hellwig:
> On Wed, Apr 06, 2011 at 07:41:37AM +0100, Stefan Hajnoczi wrote:
>> Yes, split images are not supported by block/vpc.c.
> 
> I'm working on that feature for vmdk right now, which is quite
> interesting as vmdk really is two different format both claiming
> to be vmdk, of which one is simply a text file telling how other
> vmdk images are glued together.

Last time I checked the other one wasn't a single format either, but
rather something like ten different subformats.

Anyway, if you're working on split VMDK images, I should probably stop
advertising it as a GSoC project?

Kevin

Re: [Qemu-devel] GSoC - QCOW2 <-> QED image converter

[Christoph Hellwig]

On Wed, Apr 06, 2011 at 05:15:29PM +0200, Kevin Wolf wrote:
> Am 06.04.2011 17:06, schrieb Christoph Hellwig:
> > On Wed, Apr 06, 2011 at 07:41:37AM +0100, Stefan Hajnoczi wrote:
> >> Yes, split images are not supported by block/vpc.c.
> > 
> > I'm working on that feature for vmdk right now, which is quite
> > interesting as vmdk really is two different format both claiming
> > to be vmdk, of which one is simply a text file telling how other
> > vmdk images are glued together.
> 
> Last time I checked the other one wasn't a single format either, but
> rather something like ten different subformats.

The binary vmdk files have a few different revisions too, yes.

> Anyway, if you're working on split VMDK images, I should probably stop
> advertising it as a GSoC project?

I didn't know it was advertised, but there's indeed no need to duplicate the
work.

Re: [Qemu-devel] GSoC - QCOW2 <-> QED image converter

[Lyu Mitnick]

[-- Attachment #1: Type: text/plain, Size: 1471 bytes --]

Hello Christoph,

2011/4/6 Christoph Hellwig <hch@lst.de>

> On Wed, Apr 06, 2011 at 05:15:29PM +0200, Kevin Wolf wrote:
> > Am 06.04.2011 17:06, schrieb Christoph Hellwig:
> > > On Wed, Apr 06, 2011 at 07:41:37AM +0100, Stefan Hajnoczi wrote:
> > >> Yes, split images are not supported by block/vpc.c.
> > >
> > > I'm working on that feature for vmdk right now, which is quite
> > > interesting as vmdk really is two different format both claiming
> > > to be vmdk, of which one is simply a text file telling how other
> > > vmdk images are glued together.
> >
> > Last time I checked the other one wasn't a single format either, but
> > rather something like ten different subformats.
>
> The binary vmdk files have a few different revisions too, yes.
>
> > Anyway, if you're working on split VMDK images, I should probably stop
> > advertising it as a GSoC project?
>
> I didn't know it was advertised, but there's indeed no need to duplicate
> the
> work.
>
>
Would you mind to share your solution about this feature?? My idea is
replace
all bdrv_pread(), bdrv_pwrite_sync(), bdrv_pwrite() in block/vpc.c to
bdrv_pread_split(),  bdrv_pwrite_sync_split(), bdrv_pwrite_split()
corresponding.
bdrv_pread_split(),  bdrv_pwrite_sync_split(), bdrv_pwrite_split() should
deal with
data splitted at different files via bdrv_pread(), bdrv_pwrite_sync(),
bdrv_pwrite(),
give an interface of sequential byte accessed. Is it suitable to solve this
issue??

Thanks a lot

Mitnick

[-- Attachment #2: Type: text/html, Size: 1999 bytes --]

Re: [Qemu-devel] GSoC - QCOW2 <-> QED image converter

[Christoph Hellwig]

On Thu, Apr 07, 2011 at 07:10:00AM +0800, Lyu Mitnick wrote:
> Would you mind to share your solution about this feature?? My idea is
> replace
> all bdrv_pread(), bdrv_pwrite_sync(), bdrv_pwrite() in block/vpc.c to
> bdrv_pread_split(),  bdrv_pwrite_sync_split(), bdrv_pwrite_split()
> corresponding.
> bdrv_pread_split(),  bdrv_pwrite_sync_split(), bdrv_pwrite_split() should
> deal with
> data splitted at different files via bdrv_pread(), bdrv_pwrite_sync(),
> bdrv_pwrite(),
> give an interface of sequential byte accessed. Is it suitable to solve this
> issue??

For the synchronous bdrv_read/bdrv_write used in vmdk the problem actually
is rather trivial, as it already split it's reads/write on a cluster
boundary internally, and the higher level split is always alignment to
a cluster boundary.  So basically no new work there.