XS used to save local time(not GMC) into VHD file, it is fine with XS pool , because normally all hosts in a XS pool have same time zone. But in Cloudstack, Cloudstack might move volume (VHD file) to different cluster (XS pool) with different time zone, which may cause timestamp in VHD file is in the future compared to the XS host, XS consider this VHD file as invalid. Faketime is a workaround for this.
XS fixed this issue in XS 6.2. Maybe after the EOL of XS version before XS 6.2, we can remove faketime. Anthony -----Original Message----- From: Chiradeep Vittal Sent: Thursday, February 27, 2014 10:30 PM To: dev@cloudstack.apache.org Cc: Anthony Xu Subject: Re: faketime? XenServer does not like it if the timestamp in the vhd metadata is in the future. This can happen when templates are created in a timezone that is ahead and made available to an XS that is in an earlier timezone.. On 2/27/14, 8:00 AM, "Daan Hoogland" <daan.hoogl...@gmail.com> wrote: >LS, > >Why do we use faketime in the template conversion for xen? It seems >unnecessary. > >$ faketime 2010-01-01 vhd-util convert -s 0 -t 1 -i img.raw -o >stagefixed.vhd Fail to get source file size. >Fail to convert RAW disk to VHD fixed disk. > >$ faketime 2014-01-01 vhd-util convert -s 0 -t 1 -i img.raw -o >stagefixed.vhd Fail to get source file size. >Fail to convert RAW disk to VHD fixed disk. > >$ vhd-util convert -s 0 -t 1 -i img.raw -o stagefixed.vhd >NOTE: For better performance, we will do the overwritten convert! >Done! Convert to stagefixed.vhd. > >the second call of faketime is not in the way, so I don't mind that >one;) > >-- >Daan
