Using VMotion to move informix server

Hi folks, We are trying to use VMWare VMotion software to do a physical to virtual machine conversion of a box running Informix. Vmotion is a converter tool that can be used to convert a physical machine to a virtual machine running on VM ESXi server. We are seeing issues with the dbspace files after converting the physical box to a virtual one. The dbspace files for one of the chunks is running out of disk space (free size is zero post migration). The suspicion is that the VMotion tool does not understand the internal formats of the dbspaces files. VMotion has issues with "raw disk" files. * Has anyone successfully migrated their Informix servers from a physical server to ESXi 5.0 VM server using the VMotion tool? * Has anyone seen the "dbspace running out of disk space" issue when migrating from physical to virtual machine? If so, how did you resolve it? * What could cause the dbspaces size to grow? Is the size tied to disk layout of the file? * Is there any way (any tool/scripts?) to compact/repack the dbspaces to the original size? Right now, other than the database, the rest of the system is working fine. Only the database is problematic because dbspaces reports free size as zero. Any suggestions/hints/solutions to troubleshoot/resolve the problem will be helpful. Regards, Mahesh

The problem is likely that Informix does not initialize the unused portions of RAW disk chunks that it uses so the unused portion of each RAW chunk is most likely filled with binary zeroes. The VMotion utility is assuming normal file behavior and truncating the NULL portion of the chunks when it creates the mapped files in the VM. Informix tries to write a new page to what it thinks is an already allocated fixed length file or a certain size and finds that it gets an EOF error because VMotion truncated the file. Keep in mind that these kind of physical level disk copies an only be successfully performed on Informix chunks with the engine either completely offline or in a blocked state (onmode -c BLOCK)! Here's what you have to do: 1. Use dd to look at the last "page" of each chunk. If that page is all NULLs then - Use dd to write anything to that last page. Since Informix expects that it contains garbage it will overwrite whatever you put there when it finally needs to use that space. 2. If it contains data, then LEAVE IT ALONE, this chunk will be OK! Example: (SEE THE WARNING AT THE END OF THIS RESPONSE BEFORE DOING ANYTHING!) Say you have a chunk that contains 100,000 2K pages, so its size in onstat -d is 100000, check the last page with: dd if=/my/chunk/path bs=2k count=1 skip=99999 2>/dev/null | sum If the page is empty (ie nulls) then the output from sum will look like: 00000 2 The zero checksum is only possible if the page contains no data except zeros, not even garbage. If you get a non-zero checksum, you may want to make sure that the page doesn't contain some data but still ends in zero bytes by piping it to "od -x" instead. Chunks like this should be patched as well. Then overwrite the last page: ls -l | dd of=/my/chunk/path bs=2k count=1 seek=99999 WARNING - DO NOT DO THIS WITH A FILESYSTEM CHUNK because dd will truncate the file destroying your data when it opens it for writing YOU CAN ONLY DO THIS SAFELY FOR A RAW DEVICE BASED CHUNK!!!!!!!!!!!!!! BEFORE YOU DO ANYTHING LIKE THIS, make sure that you have a viable archive of the server in hand that's been tested with archecker or by trying to restore it to another machine. Art Art S. Kagel Advanced DataTools (www.advancedatatools.com) Blog: http://informix-myview.blogspot.com/ Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on my employer, Advanced DataTools, the IIUG, nor any other organization with which I am associated either explicitly, implicitly, or by inference. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves. On Tue, Jun 11, 2013 at 11:14 AM, S M MAHESH <smahesh@cisco.com> wrote: > Hi folks, > > We are trying to use VMWare VMotion software to do a physical to virtual > machine conversion of a box running Informix. Vmotion is a converter tool > that > can be used to convert a physical machine to a virtual machine running on > VM > ESXi server. We are seeing issues with the dbspace files after converting > the > physical box to a virtual one. The dbspace files for one of the chunks is > running out of disk space (free size is zero post migration). > > The suspicion is that the VMotion tool does not understand the internal > formats of the dbspaces files. VMotion has issues with "raw disk" files. > > * Has anyone successfully migrated their Informix servers from a physical > server to ESXi 5.0 VM server using the VMotion tool? > > * Has anyone seen the "dbspace running out of disk space" issue when > migrating > from physical to virtual machine? If so, how did you resolve it? > > * What could cause the dbspaces size to grow? Is the size tied to disk > layout > of the file? > > * Is there any way (any tool/scripts?) to compact/repack the dbspaces to > the > original size? > > Right now, other than the database, the rest of the system is working fine. > Only the database is problematic because dbspaces reports free size as > zero. > > Any suggestions/hints/solutions to troubleshoot/resolve the problem will be > helpful. > > Regards, > Mahesh > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --089e013d192005d37604dee2ea16

<cutting> > Then overwrite the last page: > > ls -l | dd of=/my/chunk/path bs=2k count=1 seek=99999 > > WARNING - DO NOT DO THIS WITH A FILESYSTEM CHUNK because dd will truncate > the file destroying your data when it opens it for writing YOU CAN ONLY DO > THIS SAFELY FOR A RAW DEVICE BASED CHUNK!!!!!!!!!!!!!! Use the ontrunc option and you should be fine </cutting> > > BEFORE YOU DO ANYTHING LIKE THIS, make sure that you have a viable archive > of the server in hand that's been tested with archecker or by trying to > restore it to another machine. > > Art > > Art S. Kagel > Advanced DataTools (www.advancedatatools.com) > Blog: http://informix-myview.blogspot.com/ > > Disclaimer: Please keep in mind that my own opinions are my own opinions > and do not reflect on my employer, Advanced DataTools, the IIUG, nor any > other organization with which I am associated either explicitly, > implicitly, or by inference. Neither do those opinions reflect those of > other individuals affiliated with any entity with which I am affiliated > nor > those of the entities themselves. > > On Tue, Jun 11, 2013 at 11:14 AM, S M MAHESH <smahesh@cisco.com> wrote: > >> Hi folks, >> >> We are trying to use VMWare VMotion software to do a physical to virtual >> machine conversion of a box running Informix. Vmotion is a converter >> tool >> that >> can be used to convert a physical machine to a virtual machine running >> on >> VM >> ESXi server. We are seeing issues with the dbspace files after >> converting >> the >> physical box to a virtual one. The dbspace files for one of the chunks >> is >> running out of disk space (free size is zero post migration). >> >> The suspicion is that the VMotion tool does not understand the internal >> formats of the dbspaces files. VMotion has issues with "raw disk" files. >> >> * Has anyone successfully migrated their Informix servers from a >> physical >> server to ESXi 5.0 VM server using the VMotion tool? >> >> * Has anyone seen the "dbspace running out of disk space" issue when >> migrating >> from physical to virtual machine? If so, how did you resolve it? >> >> * What could cause the dbspaces size to grow? Is the size tied to disk >> layout >> of the file? >> >> * Is there any way (any tool/scripts?) to compact/repack the dbspaces to >> the >> original size? >> >> Right now, other than the database, the rest of the system is working >> fine. >> Only the database is problematic because dbspaces reports free size as >> zero. >> >> Any suggestions/hints/solutions to troubleshoot/resolve the problem will >> be >> helpful. >> >> Regards, >> Mahesh >> >> >> >> > ******************************************************************************* >> Forum Note: Use "Reply" to post a response in the discussion forum. >> >> > > --089e013d192005d37604dee2ea16 > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > -- Paul Watson Tel: +1 913-674-0360 Mob: +1 913-387-7529 Web: www.oninit.com www.advancedatatools.com Failure is not as frightening as regret. If you want to improve, be content to be thought foolish and stupid. What this country needs are more unemployed politicians

Hi Art, I will try your suggestion to check the last page of the chunk. I missed providing additional information about the server in my earlier email. OS: Linux (RHEL5) Informix : v11.50 dbspaces uses cooked file (not raw device) and with direct_io enabled. One more thing, we did do the P2V migration with the server online. I will retest with engine offline/blocked. Regards, Mahesh

DO NOT USE dd to write to COOKED filesystem based chunks! You can read and check the last page, but DO NOT TRY TO UPDATE IT with dd (OK you can if you are VERY careful to include the rewrite flag to the oflag=<flag,flag> option of dd, I would avoid even trying). Besides, Informix always writes to every page of a COOKED chunk at chunk creation time to avoid having the operating system allocate a sparse file that will have physical disk pages allocated to it later so that the chunk file will be as contiguous as the OS can make it initially. VMotion should NOT be truncating these files, something else is going on. Art Art S. Kagel Advanced DataTools (www.advancedatatools.com) Blog: http://informix-myview.blogspot.com/ Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on my employer, Advanced DataTools, the IIUG, nor any other organization with which I am associated either explicitly, implicitly, or by inference. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves. On Tue, Jun 11, 2013 at 12:19 PM, S M MAHESH <smahesh@cisco.com> wrote: > Hi Art, > > I will try your suggestion to check the last page of the chunk. > > I missed providing additional information about the server in my earlier > email. > > OS: Linux (RHEL5) > Informix : v11.50 > dbspaces uses cooked file (not raw device) and with direct_io enabled. > > One more thing, we did do the P2V migration with the server online. I will > retest with engine offline/blocked. > > Regards, > Mahesh > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --001a11c374206568d304dee35d26