> > >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. > > I'm not sure to understand your question currently here is a quick summary of what is happening:
1) I create a new VM with system offering specifing Storage tag NAS2 (template is on the secondary storage, and created from a VM on another zone) 2) The VM is created on NAS2 everything is fine (ROOT disk on NAS2) 3) I go in the management interface and add a new volume 4) The DATA disk for the VM is created on NAS1 and not NAS2 5) Now if I use this disk to increase the filesystem of the VM in a situation with a VM and its disks spread on 2 storage, So I was just wondering if there was a way to create an additional volume on a specifc primary, to avoid this kind of problem. > > >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? > > We don't have specific snapshot/replication on the primaries storage. Please note that the problem arise with different storage from different vendors/technology and we have no data corruption on other NFS share of these storages). The only things that seems to create this problem is that we are in a multiple primary architecture. This make us believe that the problem is more related with how Cloudstack manages the systems images when one of the primary is becoming unavailable. However we have not yet able to determine what was really going on. We also noted that when a primary is becoming unavailable, and hosts go in Alert mode, it is no more possible to deploy VM on the node even if the other primaries and the secondary are perfectly fine (this coupled with the HA script that was rebooting node and making the whole infra goes down if one primary goes offline, make us believe that in the future we will go for a multi-cluster architecture with one primary rather than a big cluster with multi-primary) Thanks! AG -- > Æ > > > >
