-2

Good afternoon,

When having to restore a virtual machine from a backed-up OVA file, should you select the source as the actual file itself or should you create a copy of the backed up file before importing? I am not sure if anything during the restoration process could potentially affect the OVA file itself (loss of network connection, cancelled import, etc.) or if the restoration process is simply reading from the OVA file. Ex.

OVA Location = /backup/mainServer.ova

Should you import an OVA directly from /backup/mainServer.ova or should you...

cp /backup/mainServer.ova /tmp/mainServer.ova

and THEN proceed to import the OVA from /tmp/mainServer.ova

From my understanding an OVA is made up of the files that are needed individually from VM/ESXI although it is not apparent if while importing the software is able to merely read the file and pull the necessary information or if the file is modified/opened or accessed in in any way that could have a possibility of corrupting the file based off errors or unexpected actions during the import process itself.

I have checked the file during uploading and I cannot see a way to tell if the file is modified/access or just read from. Hash sums are the same before/after so nothing is "modified". But that does not mean that the file isn't accessed in a way that could corrupt it from the actual import process.

IT_User
  • 211
  • 1
  • 2
  • 15
  • Yes it could be corrupted, there could be a solar flare or a stray neutrino .. If you're really bothered make the file read only or even make it immutable. – user9517 Mar 23 '16 at 22:27
  • Back to my discussion with EEAA, I know there are a million things that could happen to corrupt a file. I merely am trying to learn if there is possibility of corruption based on "OVA import process" and the way OVA's are setup. Specifically based on the OVA import process and the way the OVA process accesses the file which I am unfamiliar with. When you state make it immutable, further lock the file down past "read-only"? – IT_User Mar 23 '16 at 22:31

1 Answers1

2

Restoration should only read the file.

But seriously.

If you're that concerned about it, and if you truly only have a single copy of this OVA, then back it up somewhere else. This seems like a truly silly question to be asking, when the solution to your concerns is so simple.

EEAA
  • 108,414
  • 18
  • 172
  • 242
  • I know it "should". That's why I asked my question to know without a doubt or not as I could not find an answer as to how exactly vmware handles the restoration process. Especially seeing as OVA is made up of multiple files internally that consist of the entire vm. That's why there is redhat and virtual machine tags. I always make a copy which seems like a pointless step if it is not needed, and just because I am "concerned" does not mean I should not further my knowledge on the subject. – IT_User Mar 23 '16 at 21:42
  • 1
    Well, try the restore and find out if the file is modified. We cannot know *the precise way* your system is set up. So try it - it's simple enough to do. – EEAA Mar 23 '16 at 21:44
  • I do not know how to tell, as far as I can see he file sits there and does not change in any way. But I am by no means a Red hat expert which is why I was hoping someone from the community with extensive Red Hat VM experience could inform me. – IT_User Mar 23 '16 at 22:00
  • 1
    Take an md5 or sha2 hash of the file before and after. If they match, the file hasn't changed. – EEAA Mar 23 '16 at 22:01
  • I am not trying to come-off as rude in any way, so please do not take it that way. I just fail to see how what you provided is an answer. I know that restoration just reads a file (in most cases). For my case I could not find an answer which is what from my understanding the whole StackExchange was for. – IT_User Mar 23 '16 at 22:03
  • Wouldn't the file be set to the same hash after the restoration is complete though? – IT_User Mar 23 '16 at 22:04
  • Yes, we provide answers to questions. In this case, though, it is not apparent that you even did the bare minimum to sort out the answer for yourself. It's trivial to test, but that wasn't done. – EEAA Mar 23 '16 at 22:04
  • If a file changes, the hash changes. Take a hash, record it, do your restore, then take the hash again and compare. This is sysadmin 101. – EEAA Mar 23 '16 at 22:05
  • My question is not if the file is modified (is not). My question is if there is a possibility for the file to become corrupt based on the import process. If it was merely reading from the file and the process failed in an unexpected way I would expect the file to remain intact and just be-able to restart the process. But if the file is not just read from but "opened up for viewing", then I would suspect there to be chances of corruption... – IT_User Mar 23 '16 at 22:13
  • There is possibility for file corruption at **any point**, whether or not the file is being accessed. This is what backups are for. Honestly, this seems like a completely pointless discussion. Take good backups, do your restore. – EEAA Mar 23 '16 at 22:15
  • I know that files can become corrupt at any point, even when they are merely sitting there never being read/opened. My question had to do explicitly with unexpected errors in the "OVA import process" potentially causing corruption because of how the files is access/read from. – IT_User Mar 23 '16 at 22:20
  • Pretty much was looking for a specific answer regarding corruption possibility in the "OVA import process" specifically because of random errors during the "import process" – IT_User Mar 23 '16 at 22:21
  • Well then: sure, there could be a random error. Just like those that could happen **at any other point in your server's life**. – EEAA Mar 23 '16 at 22:21
  • Thank you for the professional help EEAA. I will go ahead and accept your answer if nothing better comes in. – IT_User Mar 23 '16 at 22:22
  • 1
    I rest my case ;( – user9517 Mar 23 '16 at 22:31