[Qemu-devel] vpc size reporting problem

[Qemu-devel] vpc size reporting problem

[Chun Yan Liu]

While testing with a 1GB VHD file created on win7, found that the VHD file
size reported on Windows is different from that is reported by qemu-img
info or within a Linux KVM guest.

Created a dynamic VHD file on win7, on Windows, it is reported 1024MB
(2097152 sectors). But with qemu-img info or within a Linux KVM guest,
it is reported 1023MB (2096640 sectors).

The values in the footer_buf are as follows:
creator_app: "win "
cylinders: 0x820 (2080)
heads: 0x10 (16)
cyl/sec: 0x3f (63)
current_size: 0x40000000 (1G)

So, if using current_size, it's correct; but using CHS will get a smaller size.

Should we add a check in this case and use "current_size" instead of
CHS?

BTW, before commit 0444dceee, there is a similar check for 'd2v',
if creator_app is 'd2v', using "size" instead of CHS. But in commit
0444dceee, this check is removed. To me, the new check and 'd2v'
check seem to be two different cases, why removing 'd2v' check?

Thanks,
Chunyan

Re: [Qemu-devel] vpc size reporting problem

[Peter Lieven]

Am 06.07.2015 um 11:44 schrieb Chun Yan Liu:
> While testing with a 1GB VHD file created on win7, found that the VHD file
> size reported on Windows is different from that is reported by qemu-img
> info or within a Linux KVM guest.
>
> Created a dynamic VHD file on win7, on Windows, it is reported 1024MB
> (2097152 sectors). But with qemu-img info or within a Linux KVM guest,
> it is reported 1023MB (2096640 sectors).
>
> The values in the footer_buf are as follows:
> creator_app: "win "
> cylinders: 0x820 (2080)
> heads: 0x10 (16)
> cyl/sec: 0x3f (63)
> current_size: 0x40000000 (1G)
>
> So, if using current_size, it's correct; but using CHS will get a smaller size.
>
> Should we add a check in this case and use "current_size" instead of
> CHS?

As far as I remember the issue was and still is that there is no official spec that says
use current_size in case A and CHS in case B.

If currrent_size is greater than CHS and Windows would use CHS (we don't
know that) we might run into issues if Qemu uses current_size. In this
cas we would write data beyond the end of the container (from Windows
perspective).

>
> BTW, before commit 0444dceee, there is a similar check for 'd2v',
> if creator_app is 'd2v', using "size" instead of CHS. But in commit
> 0444dceee, this check is removed. To me, the new check and 'd2v'
> check seem to be two different cases, why removing 'd2v' check?

d2v always writes a magic combination of 65535x16x255 for CHS. So commit
0444dceee just changed the behaviour to always use current_size in
case CHS is 65535x16x255 (including d2v).

I personally wouldn't mind to always use current_size that is what e.g. VirtualBox does.
Or use current_size if it is greater than the size derived from CHS. But this might
break things.

Peter

Re: [Qemu-devel] vpc size reporting problem

[Chun Yan Liu]

>>> On 7/6/2015 at 06:42 PM, in message <559A5B79.4010707@kamp.de>, Peter Lieven
<pl@kamp.de> wrote: 
> Am 06.07.2015 um 11:44 schrieb Chun Yan Liu: 
> > While testing with a 1GB VHD file created on win7, found that the VHD file 
> > size reported on Windows is different from that is reported by qemu-img 
> > info or within a Linux KVM guest. 
> > 
> > Created a dynamic VHD file on win7, on Windows, it is reported 1024MB 
> > (2097152 sectors). But with qemu-img info or within a Linux KVM guest, 
> > it is reported 1023MB (2096640 sectors). 
> > 
> > The values in the footer_buf are as follows: 
> > creator_app: "win " 
> > cylinders: 0x820 (2080) 
> > heads: 0x10 (16) 
> > cyl/sec: 0x3f (63) 
> > current_size: 0x40000000 (1G) 
> > 
> > So, if using current_size, it's correct; but using CHS will get a smaller  
> size. 
> > 
> > Should we add a check in this case and use "current_size" instead of 
> > CHS? 
>  
> As far as I remember the issue was and still is that there is no official  
> spec that says 
> use current_size in case A and CHS in case B. 

Understand.

>  
> If currrent_size is greater than CHS and Windows would use CHS (we don't 
> know that) we might run into issues if Qemu uses current_size. In this 
> cas we would write data beyond the end of the container (from Windows 
> perspective). 

That's right. The fact is in our testing we found Windows does not use CHS
but current_size (from testing result), we create and get the VHD parted on
Windows, then take the VHD file into Linux KVM guest, it fails to show partition
table (since the reported disk size is shrinking, some of the partitions extend
beyond the end of the disk).

>  
> > 
> > BTW, before commit 0444dceee, there is a similar check for 'd2v', 
> > if creator_app is 'd2v', using "size" instead of CHS. But in commit 
> > 0444dceee, this check is removed. To me, the new check and 'd2v' 
> > check seem to be two different cases, why removing 'd2v' check? 
>  
> d2v always writes a magic combination of 65535x16x255 for CHS. So commit 
> 0444dceee just changed the behaviour to always use current_size in 
> case CHS is 65535x16x255 (including d2v). 

Got it. Thanks!

- Chunyan

>  
> I personally wouldn't mind to always use current_size that is what e.g.  
> VirtualBox does. 
> Or use current_size if it is greater than the size derived from CHS. But  
> this might 
> break things. 
>  
> Peter 
>  
>  
>  

Re: [Qemu-devel] vpc size reporting problem

[Peter Lieven]

Am 07.07.2015 um 03:50 schrieb Chun Yan Liu:
>
>>>> On 7/6/2015 at 06:42 PM, in message <559A5B79.4010707@kamp.de>, Peter Lieven
> <pl@kamp.de> wrote:
>> Am 06.07.2015 um 11:44 schrieb Chun Yan Liu:
>>> While testing with a 1GB VHD file created on win7, found that the VHD file
>>> size reported on Windows is different from that is reported by qemu-img
>>> info or within a Linux KVM guest.
>>>
>>> Created a dynamic VHD file on win7, on Windows, it is reported 1024MB
>>> (2097152 sectors). But with qemu-img info or within a Linux KVM guest,
>>> it is reported 1023MB (2096640 sectors).
>>>
>>> The values in the footer_buf are as follows:
>>> creator_app: "win "
>>> cylinders: 0x820 (2080)
>>> heads: 0x10 (16)
>>> cyl/sec: 0x3f (63)
>>> current_size: 0x40000000 (1G)
>>>
>>> So, if using current_size, it's correct; but using CHS will get a smaller
>> size.
>>> Should we add a check in this case and use "current_size" instead of
>>> CHS?
>>   
>> As far as I remember the issue was and still is that there is no official
>> spec that says
>> use current_size in case A and CHS in case B.
> Understand.
>
>>   
>> If currrent_size is greater than CHS and Windows would use CHS (we don't
>> know that) we might run into issues if Qemu uses current_size. In this
>> cas we would write data beyond the end of the container (from Windows
>> perspective).
> That's right. The fact is in our testing we found Windows does not use CHS
> but current_size (from testing result), we create and get the VHD parted on
> Windows, then take the VHD file into Linux KVM guest, it fails to show partition
> table (since the reported disk size is shrinking, some of the partitions extend
> beyond the end of the disk).

Which version of Windows are you referring to?

I personally think that it might be ok to use current_size if its greater
than the size derived from CHS. Our current implementation when
creating an image assumes we have to choose CHS to be equal
or greater to current_size. This can cause the same issue in the
other direction.

Peter

Re: [Qemu-devel] vpc size reporting problem

[Chun Yan Liu]

>>> On 7/7/2015 at 01:50 PM, in message <559B68B2.5060402@kamp.de>, Peter Lieven
<pl@kamp.de> wrote: 
> Am 07.07.2015 um 03:50 schrieb Chun Yan Liu: 
> > 
> >>>> On 7/6/2015 at 06:42 PM, in message <559A5B79.4010707@kamp.de>, Peter Lieven 
> > <pl@kamp.de> wrote: 
> >> Am 06.07.2015 um 11:44 schrieb Chun Yan Liu: 
> >>> While testing with a 1GB VHD file created on win7, found that the VHD file 
> >>> size reported on Windows is different from that is reported by qemu-img 
> >>> info or within a Linux KVM guest. 
> >>> 
> >>> Created a dynamic VHD file on win7, on Windows, it is reported 1024MB 
> >>> (2097152 sectors). But with qemu-img info or within a Linux KVM guest, 
> >>> it is reported 1023MB (2096640 sectors). 
> >>> 
> >>> The values in the footer_buf are as follows: 
> >>> creator_app: "win " 
> >>> cylinders: 0x820 (2080) 
> >>> heads: 0x10 (16) 
> >>> cyl/sec: 0x3f (63) 
> >>> current_size: 0x40000000 (1G) 
> >>> 
> >>> So, if using current_size, it's correct; but using CHS will get a smaller 
> >> size. 
> >>> Should we add a check in this case and use "current_size" instead of 
> >>> CHS? 
> >>    
> >> As far as I remember the issue was and still is that there is no official 
> >> spec that says 
> >> use current_size in case A and CHS in case B. 
> > Understand. 
> > 
> >>    
> >> If currrent_size is greater than CHS and Windows would use CHS (we don't 
> >> know that) we might run into issues if Qemu uses current_size. In this 
> >> cas we would write data beyond the end of the container (from Windows 
> >> perspective). 
> > That's right. The fact is in our testing we found Windows does not use CHS 
> > but current_size (from testing result), we create and get the VHD parted on 
> > Windows, then take the VHD file into Linux KVM guest, it fails to show  
> partition 
> > table (since the reported disk size is shrinking, some of the partitions  
> extend 
> > beyond the end of the disk). 
>  
> Which version of Windows are you referring to? 

Tested with WS2012R2 and Win7.

>  
> I personally think that it might be ok to use current_size if its greater 
> than the size derived from CHS. Our current implementation when 
> creating an image assumes we have to choose CHS to be equal 
> or greater to current_size. This can cause the same issue in the 
> other direction. 
>  
> Peter 
>  
>  

Re: [Qemu-devel] vpc size reporting problem

[Peter Lieven]

Am 07.07.2015 um 07:59 schrieb Chun Yan Liu:
>
>>>> On 7/7/2015 at 01:50 PM, in message <559B68B2.5060402@kamp.de>, Peter Lieven
> <pl@kamp.de> wrote:
>> Am 07.07.2015 um 03:50 schrieb Chun Yan Liu:
>>>>>> On 7/6/2015 at 06:42 PM, in message <559A5B79.4010707@kamp.de>, Peter Lieven
>>> <pl@kamp.de> wrote:
>>>> Am 06.07.2015 um 11:44 schrieb Chun Yan Liu:
>>>>> While testing with a 1GB VHD file created on win7, found that the VHD file
>>>>> size reported on Windows is different from that is reported by qemu-img
>>>>> info or within a Linux KVM guest.
>>>>>
>>>>> Created a dynamic VHD file on win7, on Windows, it is reported 1024MB
>>>>> (2097152 sectors). But with qemu-img info or within a Linux KVM guest,
>>>>> it is reported 1023MB (2096640 sectors).
>>>>>
>>>>> The values in the footer_buf are as follows:
>>>>> creator_app: "win "
>>>>> cylinders: 0x820 (2080)
>>>>> heads: 0x10 (16)
>>>>> cyl/sec: 0x3f (63)
>>>>> current_size: 0x40000000 (1G)
>>>>>
>>>>> So, if using current_size, it's correct; but using CHS will get a smaller
>>>> size.
>>>>> Should we add a check in this case and use "current_size" instead of
>>>>> CHS?
>>>>     
>>>> As far as I remember the issue was and still is that there is no official
>>>> spec that says
>>>> use current_size in case A and CHS in case B.
>>> Understand.
>>>
>>>>     
>>>> If currrent_size is greater than CHS and Windows would use CHS (we don't
>>>> know that) we might run into issues if Qemu uses current_size. In this
>>>> cas we would write data beyond the end of the container (from Windows
>>>> perspective).
>>> That's right. The fact is in our testing we found Windows does not use CHS
>>> but current_size (from testing result), we create and get the VHD parted on
>>> Windows, then take the VHD file into Linux KVM guest, it fails to show
>> partition
>>> table (since the reported disk size is shrinking, some of the partitions
>> extend
>>> beyond the end of the disk).
>>   
>> Which version of Windows are you referring to?
> Tested with WS2012R2 and Win7.

Which storage driver?

I had a look at the specs and in fact they more or less say: Use current_size
and if you have an ATA controller derive the disk size from CHS.

Peter

Re: [Qemu-devel] vpc size reporting problem

[Chun Yan Liu]

>>> On 7/7/2015 at 02:03 PM, in message <559B6BBE.3050500@kamp.de>, Peter Lieven
<pl@kamp.de> wrote: 
> Am 07.07.2015 um 07:59 schrieb Chun Yan Liu: 
> > 
> >>>> On 7/7/2015 at 01:50 PM, in message <559B68B2.5060402@kamp.de>, Peter Lieven 
> > <pl@kamp.de> wrote: 
> >> Am 07.07.2015 um 03:50 schrieb Chun Yan Liu: 
> >>>>>> On 7/6/2015 at 06:42 PM, in message <559A5B79.4010707@kamp.de>, Peter Lieven 
> >>> <pl@kamp.de> wrote: 
> >>>> Am 06.07.2015 um 11:44 schrieb Chun Yan Liu: 
> >>>>> While testing with a 1GB VHD file created on win7, found that the VHD file 
> >>>>> size reported on Windows is different from that is reported by qemu-img 
> >>>>> info or within a Linux KVM guest. 
> >>>>> 
> >>>>> Created a dynamic VHD file on win7, on Windows, it is reported 1024MB 
> >>>>> (2097152 sectors). But with qemu-img info or within a Linux KVM guest, 
> >>>>> it is reported 1023MB (2096640 sectors). 
> >>>>> 
> >>>>> The values in the footer_buf are as follows: 
> >>>>> creator_app: "win " 
> >>>>> cylinders: 0x820 (2080) 
> >>>>> heads: 0x10 (16) 
> >>>>> cyl/sec: 0x3f (63) 
> >>>>> current_size: 0x40000000 (1G) 
> >>>>> 
> >>>>> So, if using current_size, it's correct; but using CHS will get a smaller 
> >>>> size. 
> >>>>> Should we add a check in this case and use "current_size" instead of 
> >>>>> CHS? 
> >>>>      
> >>>> As far as I remember the issue was and still is that there is no official 
> >>>> spec that says 
> >>>> use current_size in case A and CHS in case B. 
> >>> Understand. 
> >>> 
> >>>>      
> >>>> If currrent_size is greater than CHS and Windows would use CHS (we don't 
> >>>> know that) we might run into issues if Qemu uses current_size. In this 
> >>>> cas we would write data beyond the end of the container (from Windows 
> >>>> perspective). 
> >>> That's right. The fact is in our testing we found Windows does not use CHS 
> >>> but current_size (from testing result), we create and get the VHD parted on 
> >>> Windows, then take the VHD file into Linux KVM guest, it fails to show 
> >> partition 
> >>> table (since the reported disk size is shrinking, some of the partitions 
> >> extend 
> >>> beyond the end of the disk). 
> >>    
> >> Which version of Windows are you referring to? 
> > Tested with WS2012R2 and Win7. 
>  
> Which storage driver? 

I'm not sure. See from "device management" -> "disk drive", it's named as "Msft
virtual disk SCSI disk device", and from "storage controller", it has a separate
controller named as "Microsoft VHD HBA". Anyway, seems not controlled by
ATA/ATAPI.

>  
> I had a look at the specs and in fact they more or less say: Use  
> current_size 
> and if you have an ATA controller derive the disk size from CHS. 
>  
> Peter 
>  
>  
>  

Re: [Qemu-devel] vpc size reporting problem

[Peter Lieven]

Am 07.07.2015 um 08:19 schrieb Chun Yan Liu:
>
>>>> On 7/7/2015 at 02:03 PM, in message <559B6BBE.3050500@kamp.de>, Peter Lieven
> <pl@kamp.de> wrote:
>> Am 07.07.2015 um 07:59 schrieb Chun Yan Liu:
>>>>>> On 7/7/2015 at 01:50 PM, in message <559B68B2.5060402@kamp.de>, Peter Lieven
>>> <pl@kamp.de> wrote:
>>>> Am 07.07.2015 um 03:50 schrieb Chun Yan Liu:
>>>>>>>> On 7/6/2015 at 06:42 PM, in message <559A5B79.4010707@kamp.de>, Peter Lieven
>>>>> <pl@kamp.de> wrote:
>>>>>> Am 06.07.2015 um 11:44 schrieb Chun Yan Liu:
>>>>>>> While testing with a 1GB VHD file created on win7, found that the VHD file
>>>>>>> size reported on Windows is different from that is reported by qemu-img
>>>>>>> info or within a Linux KVM guest.
>>>>>>>
>>>>>>> Created a dynamic VHD file on win7, on Windows, it is reported 1024MB
>>>>>>> (2097152 sectors). But with qemu-img info or within a Linux KVM guest,
>>>>>>> it is reported 1023MB (2096640 sectors).
>>>>>>>
>>>>>>> The values in the footer_buf are as follows:
>>>>>>> creator_app: "win "
>>>>>>> cylinders: 0x820 (2080)
>>>>>>> heads: 0x10 (16)
>>>>>>> cyl/sec: 0x3f (63)
>>>>>>> current_size: 0x40000000 (1G)
>>>>>>>
>>>>>>> So, if using current_size, it's correct; but using CHS will get a smaller
>>>>>> size.
>>>>>>> Should we add a check in this case and use "current_size" instead of
>>>>>>> CHS?
>>>>>>       
>>>>>> As far as I remember the issue was and still is that there is no official
>>>>>> spec that says
>>>>>> use current_size in case A and CHS in case B.
>>>>> Understand.
>>>>>
>>>>>>       
>>>>>> If currrent_size is greater than CHS and Windows would use CHS (we don't
>>>>>> know that) we might run into issues if Qemu uses current_size. In this
>>>>>> cas we would write data beyond the end of the container (from Windows
>>>>>> perspective).
>>>>> That's right. The fact is in our testing we found Windows does not use CHS
>>>>> but current_size (from testing result), we create and get the VHD parted on
>>>>> Windows, then take the VHD file into Linux KVM guest, it fails to show
>>>> partition
>>>>> table (since the reported disk size is shrinking, some of the partitions
>>>> extend
>>>>> beyond the end of the disk).
>>>>     
>>>> Which version of Windows are you referring to?
>>> Tested with WS2012R2 and Win7.
>>   
>> Which storage driver?
> I'm not sure. See from "device management" -> "disk drive", it's named as "Msft
> virtual disk SCSI disk device", and from "storage controller", it has a separate
> controller named as "Microsoft VHD HBA". Anyway, seems not controlled by
> ATA/ATAPI.

Can you change that to IDE or ATA and check which size windows reports then?

Thanks,
Peter

Re: [Qemu-devel] vpc size reporting problem

[Chun Yan Liu]

>>> On 7/7/2015 at 02:19 PM, in message <559B6F79.237 : 102 : 21807>, Chun Yan Liu
wrote: 
> 
>  
>>>> On 7/7/2015 at 02:03 PM, in message <559B6BBE.3050500@kamp.de>, Peter Lieven 
> <pl@kamp.de> wrote:  
> > Am 07.07.2015 um 07:59 schrieb Chun Yan Liu:  
>> >  
>> >>>> On 7/7/2015 at 01:50 PM, in message <559B68B2.5060402@kamp.de>, Peter Lieven  
>> > <pl@kamp.de> wrote:  
>> >> Am 07.07.2015 um 03:50 schrieb Chun Yan Liu:  
>> >>>>>> On 7/6/2015 at 06:42 PM, in message <559A5B79.4010707@kamp.de>, Peter Lieven  
>> >>> <pl@kamp.de> wrote:  
>> >>>> Am 06.07.2015 um 11:44 schrieb Chun Yan Liu:  
>> >>>>> While testing with a 1GB VHD file created on win7, found that the VHD file  
>> >>>>> size reported on Windows is different from that is reported by qemu-img  
>> >>>>> info or within a Linux KVM guest.  
>> >>>>>  
>> >>>>> Created a dynamic VHD file on win7, on Windows, it is reported 1024MB  
>> >>>>> (2097152 sectors). But with qemu-img info or within a Linux KVM guest,  
>> >>>>> it is reported 1023MB (2096640 sectors).  
>> >>>>>  
>> >>>>> The values in the footer_buf are as follows:  
>> >>>>> creator_app: "win "  
>> >>>>> cylinders: 0x820 (2080)  
>> >>>>> heads: 0x10 (16)  
>> >>>>> cyl/sec: 0x3f (63)  
>> >>>>> current_size: 0x40000000 (1G)  
>> >>>>>  
>> >>>>> So, if using current_size, it's correct; but using CHS will get a smaller  
>> >>>> size.  
>> >>>>> Should we add a check in this case and use "current_size" instead of  
>> >>>>> CHS?  
>> >>>>       
>> >>>> As far as I remember the issue was and still is that there is no official  
>> >>>> spec that says  
>> >>>> use current_size in case A and CHS in case B.  
>> >>> Understand.  
>> >>>  
>> >>>>       
>> >>>> If currrent_size is greater than CHS and Windows would use CHS (we don't  
>> >>>> know that) we might run into issues if Qemu uses current_size. In this  
>> >>>> cas we would write data beyond the end of the container (from Windows  
>> >>>> perspective).  
>> >>> That's right. The fact is in our testing we found Windows does not use CHS  
>> >>> but current_size (from testing result), we create and get the VHD parted on  
>> >>> Windows, then take the VHD file into Linux KVM guest, it fails to show  
>> >> partition  
>> >>> table (since the reported disk size is shrinking, some of the partitions  
>> >> extend  
>> >>> beyond the end of the disk).  
>> >>     
>> >> Which version of Windows are you referring to?  
>> > Tested with WS2012R2 and Win7.  
>>   
>> Which storage driver?  

And imported to a Win7 guest on KVM as IDE device, it's also reported as
1024MB (not CHS value, CHS is 1023MB).

>  
> I'm not sure. See from "device management" -> "disk drive", it's named as  
> "Msft 
> virtual disk SCSI disk device", and from "storage controller", it has a  
> separate 
> controller named as "Microsoft VHD HBA". Anyway, seems not controlled by 
> ATA/ATAPI. 
>  
>>   
>> I had a look at the specs and in fact they more or less say: Use   
>> current_size  
>> and if you have an ATA controller derive the disk size from CHS.  
>>   
>> Peter  
>>   
>>   
>>   
>  

Re: [Qemu-devel] vpc size reporting problem

[Peter Lieven]

Am 07.07.2015 um 08:34 schrieb Chun Yan Liu:
>
>>>> On 7/7/2015 at 02:19 PM, in message <559B6F79.237 : 102 : 21807>, Chun Yan Liu
> wrote:
>>   
>>>>> On 7/7/2015 at 02:03 PM, in message <559B6BBE.3050500@kamp.de>, Peter Lieven
>> <pl@kamp.de> wrote:
>>> Am 07.07.2015 um 07:59 schrieb Chun Yan Liu:
>>>>   
>>>>>>> On 7/7/2015 at 01:50 PM, in message <559B68B2.5060402@kamp.de>, Peter Lieven
>>>> <pl@kamp.de> wrote:
>>>>> Am 07.07.2015 um 03:50 schrieb Chun Yan Liu:
>>>>>>>>> On 7/6/2015 at 06:42 PM, in message <559A5B79.4010707@kamp.de>, Peter Lieven
>>>>>> <pl@kamp.de> wrote:
>>>>>>> Am 06.07.2015 um 11:44 schrieb Chun Yan Liu:
>>>>>>>> While testing with a 1GB VHD file created on win7, found that the VHD file
>>>>>>>> size reported on Windows is different from that is reported by qemu-img
>>>>>>>> info or within a Linux KVM guest.
>>>>>>>>   
>>>>>>>> Created a dynamic VHD file on win7, on Windows, it is reported 1024MB
>>>>>>>> (2097152 sectors). But with qemu-img info or within a Linux KVM guest,
>>>>>>>> it is reported 1023MB (2096640 sectors).
>>>>>>>>   
>>>>>>>> The values in the footer_buf are as follows:
>>>>>>>> creator_app: "win "
>>>>>>>> cylinders: 0x820 (2080)
>>>>>>>> heads: 0x10 (16)
>>>>>>>> cyl/sec: 0x3f (63)
>>>>>>>> current_size: 0x40000000 (1G)
>>>>>>>>   
>>>>>>>> So, if using current_size, it's correct; but using CHS will get a smaller
>>>>>>> size.
>>>>>>>> Should we add a check in this case and use "current_size" instead of
>>>>>>>> CHS?
>>>>>>>        
>>>>>>> As far as I remember the issue was and still is that there is no official
>>>>>>> spec that says
>>>>>>> use current_size in case A and CHS in case B.
>>>>>> Understand.
>>>>>>   
>>>>>>>        
>>>>>>> If currrent_size is greater than CHS and Windows would use CHS (we don't
>>>>>>> know that) we might run into issues if Qemu uses current_size. In this
>>>>>>> cas we would write data beyond the end of the container (from Windows
>>>>>>> perspective).
>>>>>> That's right. The fact is in our testing we found Windows does not use CHS
>>>>>> but current_size (from testing result), we create and get the VHD parted on
>>>>>> Windows, then take the VHD file into Linux KVM guest, it fails to show
>>>>> partition
>>>>>> table (since the reported disk size is shrinking, some of the partitions
>>>>> extend
>>>>>> beyond the end of the disk).
>>>>>      
>>>>> Which version of Windows are you referring to?
>>>> Tested with WS2012R2 and Win7.
>>>    
>>> Which storage driver?
> And imported to a Win7 guest on KVM as IDE device, it's also reported as
> 1024MB (not CHS value, CHS is 1023MB).

And what storage driver reports 1023MB under Qemu?

Peter

Re: [Qemu-devel] vpc size reporting problem

[Chun Yan Liu]

>>> On 7/7/2015 at 02:36 PM, in message <559B7366.5030004@kamp.de>, Peter Lieven
<pl@kamp.de> wrote: 
> Am 07.07.2015 um 08:34 schrieb Chun Yan Liu: 
> > 
> >>>> On 7/7/2015 at 02:19 PM, in message <559B6F79.237 : 102 : 21807>, Chun Yan  
> Liu 
> > wrote: 
> >>    
> >>>>> On 7/7/2015 at 02:03 PM, in message <559B6BBE.3050500@kamp.de>, Peter Lieven 
> >> <pl@kamp.de> wrote: 
> >>> Am 07.07.2015 um 07:59 schrieb Chun Yan Liu: 
> >>>>    
> >>>>>>> On 7/7/2015 at 01:50 PM, in message <559B68B2.5060402@kamp.de>, Peter Lieven 
> >>>> <pl@kamp.de> wrote: 
> >>>>> Am 07.07.2015 um 03:50 schrieb Chun Yan Liu: 
> >>>>>>>>> On 7/6/2015 at 06:42 PM, in message <559A5B79.4010707@kamp.de>, Peter Lieven 
> >>>>>> <pl@kamp.de> wrote: 
> >>>>>>> Am 06.07.2015 um 11:44 schrieb Chun Yan Liu: 
> >>>>>>>> While testing with a 1GB VHD file created on win7, found that the VHD file 
> >>>>>>>> size reported on Windows is different from that is reported by qemu-img 
> >>>>>>>> info or within a Linux KVM guest. 
> >>>>>>>>    
> >>>>>>>> Created a dynamic VHD file on win7, on Windows, it is reported 1024MB 
> >>>>>>>> (2097152 sectors). But with qemu-img info or within a Linux KVM guest, 
> >>>>>>>> it is reported 1023MB (2096640 sectors). 
> >>>>>>>>    
> >>>>>>>> The values in the footer_buf are as follows: 
> >>>>>>>> creator_app: "win " 
> >>>>>>>> cylinders: 0x820 (2080) 
> >>>>>>>> heads: 0x10 (16) 
> >>>>>>>> cyl/sec: 0x3f (63) 
> >>>>>>>> current_size: 0x40000000 (1G) 
> >>>>>>>>    
> >>>>>>>> So, if using current_size, it's correct; but using CHS will get a smaller 
> >>>>>>> size. 
> >>>>>>>> Should we add a check in this case and use "current_size" instead of 
> >>>>>>>> CHS? 
> >>>>>>>         
> >>>>>>> As far as I remember the issue was and still is that there is no official 
> >>>>>>> spec that says 
> >>>>>>> use current_size in case A and CHS in case B. 
> >>>>>> Understand. 
> >>>>>>    
> >>>>>>>         
> >>>>>>> If currrent_size is greater than CHS and Windows would use CHS (we don't 
> >>>>>>> know that) we might run into issues if Qemu uses current_size. In this 
> >>>>>>> cas we would write data beyond the end of the container (from Windows 
> >>>>>>> perspective). 
> >>>>>> That's right. The fact is in our testing we found Windows does not use CHS 
> >>>>>> but current_size (from testing result), we create and get the VHD parted on 
> >>>>>> Windows, then take the VHD file into Linux KVM guest, it fails to show 
> >>>>> partition 
> >>>>>> table (since the reported disk size is shrinking, some of the partitions 
> >>>>> extend 
> >>>>>> beyond the end of the disk). 
> >>>>>       
> >>>>> Which version of Windows are you referring to? 
> >>>> Tested with WS2012R2 and Win7. 
> >>>     
> >>> Which storage driver? 
> > And imported to a Win7 guest on KVM as IDE device, it's also reported as 
> > 1024MB (not CHS value, CHS is 1023MB). 
>  
> And what storage driver reports 1023MB under Qemu? 

SCSI driver under Linux guest.

>  
> Peter
>  
>  
>  
>