On 1/25/13 7:18 AM, "Arnaud Gaillard" <arnaud.gaill...@xtendsys.net> wrote:
>Hello, > >(Our setup: cloudstack 3.0.2 on Centos + KVM + NFS fileservers from >different vendors) > >We have a multiple primary setup, but following the crash of one of the >primary storage we have realized that additional volume added to a VM were >not created with the same offering than the original VM. > >This mean that the VM was running on a specific primary and the volume we >created afterward for this VM were not following the storage tag of the >offering. Were you spinning up subsequent vm's from a template created of the original vm? Were those latter vm's using the same service offering? If so that shouldn¹t happen. > >This may create important incoherency and complexity when we do operation >with primary storage. > >Is there a way to control on which primary is created a volume? Is this a >bug? > >We also have strange behaviour following a primary storage crash with some >VM time traveling backward (the VM is up but the filesystem is in the >state >it was one month ago, this state is different from the original >template...). >Also some VM were missing huge part of their filesystem. This is also the >case for VM that were not on the impacted storage. > >The data are not corrupted on the NFS server but after the restart, the VM >are sometime in an incoherent state from a filesystem point of view. We >tried to understand what might cause this but currently we didn't come to >a >satisfactory solution. > >Did other users encountered this type of problem? > >Thanks, > >AG > There seems to be something more fundamentally wrong in your cloud env. Volumes, even after a crash, should be as recent as the crash. Do you have any data replication service/snapshotting running on your primary storage server? -- Æ
