CC'ing xen-api list. On May 30, 2012 6:31 PM, "Anthony Xu" <xuefei...@citrix.com> wrote: > > All XenServer releases include vhd-util, in that version it saves local time as timestamp in VHD file, it is probably okay with XenServer. > But with CloudStack, CloudStack may move VHD file around to XenServer with different time zone, XenServer may think the VHD file is broken because > the timestamp in the VHD file is behind its local time. > > We put the vhd-util source in tools/vhd-tools/, which is originally coming from xen 4.1 source code. We removed the check of timestamp to workaround above issue. > > The reason we need vhd-util binary is, > Vhd-util is supposed to run on XenServer host, which is a 32 bit OS. But most developer machines are 64 bit OS. > >
This isn't something that needs to be fixed, I suppose, but it might be a good idea to patch vhd-util to either ignore timestamps, as you've done, or to use utc instead. We could then put this version of vhd-util in XenServer, and work on upstreaming it to Xen. Any thoughts on this from xen-api? Mike > What's your opinion on how to handle this? > > > Thanks, > Anthony > > > > > -----Original Message----- > > From: Mike McClurg [mailto:mike.mccl...@gmail.com] > > Sent: Wednesday, May 30, 2012 1:22 AM > > To: cloudstack-dev@incubator.apache.org > > Subject: Why is the vhd-util binary committed to the CloudStack source > > repo? > > > > Hi all, > > > > I was looking in scripts/vm/hypervisor/xenserver/ when I noticed that > > the vhd-util file is actually a compiled binary. So, my questions are: > > > > 1) If this program is necessary, then is there a better way to include > > it in the source tree? Either as a dependency, or as source directly? > > 2) Is this really necessary in XenServer 6.0 and onwards? I don't have > > a previous release handy for testing, but I know that we included > > vhd-util in XenServer since 6.0. > > 3) Is there anything special about the particular version of vhd-util > > you've packaged in the git repo? Or will any recent version do? > > > > Thanks, > > > > Mike
