[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-discuss] Does QEMU support VHD images > 127GB? - #2

From: Derry Bryson
Subject: Re: [Qemu-discuss] Does QEMU support VHD images > 127GB? - #2
Date: Thu, 31 Jul 2014 15:15:00 +0000


That's the conclusion I came to as well.  I think ShadowProtect is generating a 
vhd that qemu doesn't correctly recognize.  The blktap vhd code does work with 
it, so that is what I am using for now.  Thanks for your help.


-----Original Message-----
From: Donald R Laster Jr [mailto:address@hidden 
Sent: Wednesday, July 30, 2014 1:17 PM
To: Derry Bryson
Subject: Re: [Qemu-discuss] Does QEMU support VHD images > 127GB? - #2


  As I was driving back from the office today I thought of something that might 
be the cause of your problem.  Maybe QEMU is not recognizing the version of the 
header of your VHD image and is defaulting to a basic header version.   If you 
can manage to get the header decoded you may be able to get more information 
and some better help than me. :-)



  I did a search for VHD in the qemu 2.0.0 code and ./block/vpc.c seems to have 
these comments about the image:

    // The visible size of a image in Virtual PC depends on the geometry
    // rather than on the size stored in the footer (the size in the footer
    // is too large usually)
    bs->total_sectors = (int64_t)
        be16_to_cpu(footer->cyls) * footer->heads * footer->secs_per_cyl;

    /* images created with disk2vhd report a far higher virtual size
     * than expected with the cyls * heads * sectors_per_cyl formula.
     * use the footer->size instead if the image was created with
     * disk2vhd.
    if (!strncmp(footer->creator_app, "d2v", 4)) {
        bs->total_sectors = be64_to_cpu(footer->size) / BDRV_SECTOR_SIZE;

    /* Allow a maximum disk size of approximately 2 TB */
    if (bs->total_sectors >= VHD_MAX_SECTORS) {
        ret = -EFBIG;
        goto fail;

and these:

    uint16_t    cyls;
    uint8_t     heads;
    uint8_t     secs_per_cyl;

In ./qemu-doc.texi it talks about a 

   "Specifies which VHDX subformat to use. Valid options are"




  I would agree that Windows Server 2008 R2 would not have that problem.  Is is 
possible to try manipulating the cylinders/heads/sectors that the image is 
presented with?  Maybe the interface is looking at cylinder 0 information and 
thinking it is smaller?  

   What version of qemu are you running with? Qemu 2.1.0 rc3 is on the download 
page at http://wiki.qemu.org/Download . 

  Keep in mind, while I use qemu, I do not know the internals.  Just mentioning 
things that some times get overlooked.  The VMs I am using are still running 
with 1.4 and when I get the chance will be updating.  I don't do anything fancy 
with them.  So I am not rushed to change them.

  Good luck.


Derry Bryson wrote, On 07/29/2014 11:21 AM:
> It's Windows Server 2008 R2, so I doubt that is an issue.  I think 
> it's a bug or limitation with qemu as qemu-img shows it as 127GB also.
> -----Original Message----- From: Donald R Laster Jr 
> [mailto:address@hidden Sent: Monday, July 28, 2014 5:55 PM To:
> Derry Bryson Subject: Re: [Qemu-discuss] Does QEMU support VHD images
> > 127GB?
> Derry,
> The first thing I would consider is to check the OS you are using.
> Some OSes won't see the larger drives without special drivers.  And 
> with the size you are indicating I suspect that is the issue.
> Don
> Derry Bryson wrote, On 07/28/2014 11:48 AM:
>> When I attach a vhd file that is supposed to be 500GB, it shows up as 
>> a 127GB disk.  Is there some limitation in QEMU or am I doing it  
>> wrong?
>> Thanks.
>> Derry Bryson Senior Software Engineer Highly Reliable Systems 
>> */Backup should be easy and affordable/* 775-329-5139 ext _* 129 
>> _www.High-Rely.com_ <http://www.high-rely.com/>
> --
> ======================================================================
> =====
>  Donald R. Laster Jr.
> ======================================================================
> =====

reply via email to

[Prev in Thread] Current Thread [Next in Thread]