ਲੌਗ ਕਿੱਥੋਂ ਆਉਂਦੇ ਹਨ? ਵੀਮ ਲੌਗ ਡਾਈਵਿੰਗ

ਅਸੀਂ ਅਨੁਮਾਨ ਲਗਾਉਣ ਦੀ ਦਿਲਚਸਪ ਦੁਨੀਆ ਵਿੱਚ ਆਪਣੀ ਡੁੱਬਣ ਨੂੰ ਜਾਰੀ ਰੱਖਦੇ ਹਾਂ ... ਲੌਗਸ ਦੁਆਰਾ ਸਮੱਸਿਆ ਦਾ ਨਿਪਟਾਰਾ। IN ਪਿਛਲੇ ਲੇਖ ਅਸੀਂ ਬੁਨਿਆਦੀ ਸ਼ਰਤਾਂ ਦੇ ਅਰਥਾਂ 'ਤੇ ਸਹਿਮਤ ਹੋਏ ਅਤੇ ਵੀਮ ਦੀ ਸਮੁੱਚੀ ਬਣਤਰ ਨੂੰ ਇੱਕ ਅੱਖ ਨਾਲ ਇੱਕ ਸਿੰਗਲ ਐਪਲੀਕੇਸ਼ਨ ਵਜੋਂ ਦੇਖਿਆ। ਇਸ ਦਾ ਕੰਮ ਇਹ ਪਤਾ ਲਗਾਉਣਾ ਹੈ ਕਿ ਲੌਗ ਫਾਈਲਾਂ ਕਿਵੇਂ ਬਣੀਆਂ ਹਨ, ਉਹਨਾਂ ਵਿੱਚ ਕਿਸ ਕਿਸਮ ਦੀ ਜਾਣਕਾਰੀ ਪ੍ਰਦਰਸ਼ਿਤ ਹੁੰਦੀ ਹੈ ਅਤੇ ਉਹ ਕਿਵੇਂ ਦਿਖਾਈ ਦਿੰਦੀਆਂ ਹਨ।

ਤੁਸੀਂ ਕੀ ਸੋਚਦੇ ਹੋ ਕਿ ਇਹ "ਲਾਗ" ਹਨ? ਜ਼ਿਆਦਾਤਰ ਦੇ ਅਨੁਸਾਰ, ਕਿਸੇ ਵੀ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਲੌਗਸ ਨੂੰ ਇੱਕ ਕਿਸਮ ਦੀ ਸਰਵ ਸ਼ਕਤੀਮਾਨ ਹਸਤੀ ਦੀ ਭੂਮਿਕਾ ਸੌਂਪੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ ਜੋ ਜ਼ਿਆਦਾਤਰ ਸਮਾਂ ਵਿਹੜੇ ਵਿੱਚ ਕਿਤੇ ਨਾ ਕਿਤੇ ਬਨਸਪਤੀ ਹੁੰਦੀ ਹੈ, ਪਰ ਸਹੀ ਸਮੇਂ 'ਤੇ ਚਮਕਦਾਰ ਸ਼ਸਤਰ ਵਿੱਚ ਕਿਤੇ ਵੀ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ ਅਤੇ ਸਾਰਿਆਂ ਨੂੰ ਬਚਾਉਂਦਾ ਹੈ। ਭਾਵ, ਉਹਨਾਂ ਵਿੱਚ ਹਰ ਇੱਕ ਹਿੱਸੇ ਵਿੱਚ ਮਾਮੂਲੀ ਗਲਤੀਆਂ ਤੋਂ ਲੈ ਕੇ ਵਿਅਕਤੀਗਤ ਡੇਟਾਬੇਸ ਲੈਣ-ਦੇਣ ਤੱਕ ਸਭ ਕੁਝ ਸ਼ਾਮਲ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਅਤੇ ਇਸ ਲਈ ਗਲਤੀ ਤੋਂ ਬਾਅਦ ਇਹ ਤੁਰੰਤ ਲਿਖਿਆ ਗਿਆ ਸੀ ਕਿ ਇਸ ਨੂੰ ਕਿਵੇਂ ਠੀਕ ਕਰਨਾ ਹੈ. ਅਤੇ ਇਹ ਸਭ ਕੁਝ ਮੈਗਾਬਾਈਟ ਵਿੱਚ ਫਿੱਟ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਹੋਰ ਨਹੀਂ। ਇਹ ਸਿਰਫ਼ ਪਾਠ ਹੈ! ਟੈਕਸਟ ਫਾਈਲਾਂ XNUMX ਗੀਗਾਬਾਈਟ ਨਹੀਂ ਲੈ ਸਕਦੀਆਂ, ਮੈਂ ਇਸਨੂੰ ਕਿਤੇ ਸੁਣਿਆ ਹੈ!

ਇਸ ਲਈ ਲਾਗ

ਅਸਲ ਸੰਸਾਰ ਵਿੱਚ, ਲੌਗ ਡਾਇਗਨੌਸਟਿਕ ਜਾਣਕਾਰੀ ਦਾ ਸਿਰਫ਼ ਇੱਕ ਪੁਰਾਲੇਖ ਹਨ। ਅਤੇ ਉੱਥੇ ਕੀ ਸਟੋਰ ਕਰਨਾ ਹੈ, ਸਟੋਰੇਜ ਲਈ ਜਾਣਕਾਰੀ ਕਿੱਥੋਂ ਪ੍ਰਾਪਤ ਕਰਨੀ ਹੈ ਅਤੇ ਇਹ ਕਿੰਨੀ ਵਿਸਤ੍ਰਿਤ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ, ਇਹ ਫੈਸਲਾ ਡਿਵੈਲਪਰਾਂ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ। ਕੋਈ ON / OFF ਪੱਧਰ ਦੇ ਰਿਕਾਰਡ ਰੱਖ ਕੇ ਘੱਟੋ-ਘੱਟਤਾ ਦੇ ਮਾਰਗ 'ਤੇ ਚੱਲਦਾ ਹੈ, ਅਤੇ ਕੋਈ ਪੂਰੀ ਲਗਨ ਨਾਲ ਉਹ ਸਭ ਕੁਝ ਤਿਆਰ ਕਰਦਾ ਹੈ ਜਿਸ ਤੱਕ ਉਹ ਪਹੁੰਚ ਸਕਦੇ ਹਨ। ਹਾਲਾਂਕਿ ਅਖੌਤੀ ਲੌਗਿੰਗ ਪੱਧਰ ਦੀ ਚੋਣ ਕਰਨ ਦੀ ਯੋਗਤਾ ਵਾਲਾ ਇੱਕ ਵਿਚਕਾਰਲਾ ਵਿਕਲਪ ਵੀ ਹੈ, ਜਦੋਂ ਤੁਸੀਂ ਖੁਦ ਇਹ ਦਰਸਾਉਂਦੇ ਹੋ ਕਿ ਤੁਸੀਂ ਕਿੰਨੀ ਵਿਸਤ੍ਰਿਤ ਜਾਣਕਾਰੀ ਨੂੰ ਸਟੋਰ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ ਅਤੇ ਤੁਹਾਡੇ ਕੋਲ ਕਿੰਨੀ ਵਾਧੂ ਡਿਸਕ ਸਪੇਸ ਹੈ =) VBR ਕੋਲ ਛੇ ਅਜਿਹੇ ਪੱਧਰ ਹਨ। ਅਤੇ, ਮੇਰੇ ਤੇ ਵਿਸ਼ਵਾਸ ਕਰੋ, ਤੁਸੀਂ ਇਹ ਨਹੀਂ ਦੇਖਣਾ ਚਾਹੁੰਦੇ ਹੋ ਕਿ ਤੁਹਾਡੀ ਡਿਸਕ 'ਤੇ ਖਾਲੀ ਥਾਂ ਦੇ ਨਾਲ ਸਭ ਤੋਂ ਵਿਸਤ੍ਰਿਤ ਲੌਗਿੰਗ ਨਾਲ ਕੀ ਹੁੰਦਾ ਹੈ.

ਜੁਰਮਾਨਾ. ਅਸੀਂ ਮੋਟੇ ਤੌਰ 'ਤੇ ਸਮਝ ਗਏ ਹਾਂ ਕਿ ਅਸੀਂ ਕੀ ਬਚਾਉਣਾ ਚਾਹੁੰਦੇ ਹਾਂ, ਪਰ ਇੱਕ ਜਾਇਜ਼ ਸਵਾਲ ਪੈਦਾ ਹੁੰਦਾ ਹੈ: ਇਹ ਜਾਣਕਾਰੀ ਕਿੱਥੋਂ ਪ੍ਰਾਪਤ ਕੀਤੀ ਜਾਵੇ? ਬੇਸ਼ੱਕ, ਅਸੀਂ ਆਪਣੀਆਂ ਅੰਦਰੂਨੀ ਪ੍ਰਕਿਰਿਆਵਾਂ ਦੁਆਰਾ ਆਪਣੇ ਆਪ ਨੂੰ ਲੌਗ ਕਰਨ ਲਈ ਘਟਨਾਵਾਂ ਦਾ ਹਿੱਸਾ ਬਣਾਉਂਦੇ ਹਾਂ। ਪਰ ਕੀ ਕਰਨਾ ਹੈ ਜਦੋਂ ਬਾਹਰੀ ਵਾਤਾਵਰਣ ਨਾਲ ਕੋਈ ਪਰਸਪਰ ਪ੍ਰਭਾਵ ਹੁੰਦਾ ਹੈ? ਬੈਸਾਖੀਆਂ ਅਤੇ ਸਾਈਕਲਾਂ ਦੇ ਨਰਕ ਵਿੱਚ ਨਾ ਜਾਣ ਲਈ, ਵੀਮ ਅਜਿਹੀਆਂ ਕਾਢਾਂ ਦੀ ਖੋਜ ਨਹੀਂ ਕਰਦਾ ਹੈ ਜੋ ਪਹਿਲਾਂ ਹੀ ਖੋਜੀਆਂ ਜਾ ਚੁੱਕੀਆਂ ਹਨ। ਜਦੋਂ ਵੀ ਕੋਈ ਰੈਡੀਮੇਡ ਏਪੀਆਈ, ਬਿਲਟ-ਇਨ ਫੰਕਸ਼ਨ, ਲਾਇਬ੍ਰੇਰੀ, ਆਦਿ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਅਸੀਂ ਆਪਣੇ ਕੰਟਰੈਪਸ਼ਨ ਨੂੰ ਵਾੜਨਾ ਸ਼ੁਰੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਤਿਆਰ-ਕੀਤੇ ਵਿਕਲਪਾਂ ਨੂੰ ਤਰਜੀਹ ਦੇਵਾਂਗੇ। ਹਾਲਾਂਕਿ ਬਾਅਦ ਵਾਲਾ ਵੀ ਕਾਫੀ ਹੈ। ਇਸ ਲਈ, ਲੌਗਸ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਦੇ ਸਮੇਂ, ਇਹ ਸਮਝਣਾ ਮਹੱਤਵਪੂਰਨ ਹੁੰਦਾ ਹੈ ਕਿ ਗਲਤੀਆਂ ਦਾ ਵੱਡਾ ਹਿੱਸਾ ਤੀਜੀ-ਧਿਰ API, ਸਿਸਟਮ ਕਾਲਾਂ ਅਤੇ ਹੋਰ ਲਾਇਬ੍ਰੇਰੀਆਂ ਦੇ ਸੰਦੇਸ਼ਾਂ 'ਤੇ ਪੈਂਦਾ ਹੈ। ਇਸ ਸਥਿਤੀ ਵਿੱਚ, VBR ਦੀ ਭੂਮਿਕਾ ਇਹਨਾਂ ਤਰੁਟੀਆਂ ਨੂੰ ਲੌਗ ਫਾਈਲਾਂ ਵਾਂਗ ਅੱਗੇ ਭੇਜਣ ਲਈ ਹੇਠਾਂ ਆਉਂਦੀ ਹੈ। ਅਤੇ ਉਪਭੋਗਤਾ ਦਾ ਮੁੱਖ ਕੰਮ ਇਹ ਸਮਝਣਾ ਸਿੱਖਣਾ ਹੈ ਕਿ ਕਿਹੜੀ ਲਾਈਨ ਕਿਸ ਤੋਂ ਹੈ, ਅਤੇ ਇਹ "ਕੌਣ" ਕਿਸ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਹੈ. ਇਸ ਲਈ ਜੇਕਰ VBR ਲੌਗ ਤੋਂ ਇੱਕ ਗਲਤੀ ਕੋਡ ਤੁਹਾਨੂੰ ਇੱਕ MSDN ਪੰਨੇ 'ਤੇ ਲੈ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਇਹ ਠੀਕ ਅਤੇ ਸਹੀ ਹੈ।

ਜਿਵੇਂ ਕਿ ਅਸੀਂ ਪਹਿਲਾਂ ਸਹਿਮਤ ਹੋਏ ਸੀ: ਵੀਮ ਇੱਕ ਅਖੌਤੀ SQL-ਅਧਾਰਿਤ ਐਪਲੀਕੇਸ਼ਨ ਹੈ। ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਸਾਰੀਆਂ ਸੈਟਿੰਗਾਂ, ਸਾਰੀ ਜਾਣਕਾਰੀ ਅਤੇ ਆਮ ਤੌਰ 'ਤੇ ਹਰ ਚੀਜ਼ ਜੋ ਸਿਰਫ ਆਮ ਕੰਮਕਾਜ ਲਈ ਜ਼ਰੂਰੀ ਹੈ - ਹਰ ਚੀਜ਼ ਇਸਦੇ ਡੇਟਾਬੇਸ ਵਿੱਚ ਸਟੋਰ ਕੀਤੀ ਜਾਂਦੀ ਹੈ. ਇਸ ਲਈ ਸਧਾਰਨ ਸੱਚਾਈ: ਜੋ ਲਾਗਾਂ ਵਿੱਚ ਨਹੀਂ ਹੈ, ਉਹ ਡਾਟਾਬੇਸ ਵਿੱਚ ਸਭ ਤੋਂ ਵੱਧ ਸੰਭਾਵਨਾ ਹੈ. ਪਰ ਇਹ ਸਿਲਵਰ ਬੁਲੇਟ ਵੀ ਨਹੀਂ ਹੈ: ਕੁਝ ਚੀਜ਼ਾਂ ਵੀਮ ਕੰਪੋਨੈਂਟਸ ਦੇ ਸਥਾਨਕ ਲੌਗਸ ਵਿੱਚ ਨਹੀਂ ਹਨ, ਨਾ ਹੀ ਇਸਦੇ ਡੇਟਾਬੇਸ ਵਿੱਚ। ਇਸ ਲਈ, ਤੁਹਾਨੂੰ ਇਹ ਸਿੱਖਣ ਦੀ ਲੋੜ ਹੈ ਕਿ ਹੋਸਟ ਲੌਗਸ, ਲੋਕਲ ਮਸ਼ੀਨ ਦੇ ਲੌਗਸ ਅਤੇ ਬੈਕਅੱਪ ਅਤੇ ਰੀਸਟੋਰ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਸ਼ਾਮਲ ਹਰ ਚੀਜ਼ ਦੇ ਲੌਗਸ ਦਾ ਅਧਿਐਨ ਕਿਵੇਂ ਕਰਨਾ ਹੈ। ਅਤੇ ਇਹ ਵੀ ਹੁੰਦਾ ਹੈ ਕਿ ਲੋੜੀਂਦੀ ਜਾਣਕਾਰੀ ਕਿਤੇ ਵੀ ਉਪਲਬਧ ਨਹੀਂ ਹੁੰਦੀ। ਉਹ ਤਰੀਕਾ ਹੈ। 

ਅਜਿਹੇ API ਦੇ ਕੁਝ ਉਦਾਹਰਣ

ਇਹ ਸੂਚੀ ਵਿਸ਼ੇਸ਼ ਤੌਰ 'ਤੇ ਸੰਪੂਰਨ ਹੋਣ ਦਾ ਉਦੇਸ਼ ਨਹੀਂ ਹੈ, ਇਸ ਲਈ ਇਸ ਵਿੱਚ ਅੰਤਮ ਸੱਚ ਦੀ ਖੋਜ ਕਰਨ ਦੀ ਕੋਈ ਲੋੜ ਨਹੀਂ ਹੈ। ਇਸਦਾ ਉਦੇਸ਼ ਸਿਰਫ਼ ਸਾਡੇ ਉਤਪਾਦਾਂ ਵਿੱਚ ਵਰਤੀਆਂ ਜਾਂਦੀਆਂ ਸਭ ਤੋਂ ਆਮ ਤੀਜੀ-ਧਿਰ APIs ਅਤੇ ਤਕਨਾਲੋਜੀਆਂ ਨੂੰ ਦਿਖਾਉਣਾ ਹੈ।

ਦੇ ਨਾਲ ਸ਼ੁਰੂ ਕਰੀਏ VMware. 

ਸੂਚੀ 'ਚ ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਹੋਵੇਗਾ vSphere API. ਪ੍ਰਮਾਣਿਕਤਾ, ਲੜੀ ਨੂੰ ਪੜ੍ਹਨ, ਸਨੈਪਸ਼ਾਟ ਬਣਾਉਣ ਅਤੇ ਮਿਟਾਉਣ, ਮਸ਼ੀਨਾਂ ਬਾਰੇ ਜਾਣਕਾਰੀ ਦੀ ਬੇਨਤੀ ਕਰਨ, ਅਤੇ ਹੋਰ ਬਹੁਤ ਕੁਝ (ਬਹੁਤ ਜ਼ਿਆਦਾ) ਲਈ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ। ਹੱਲ ਦੀ ਕਾਰਜਕੁਸ਼ਲਤਾ ਬਹੁਤ ਵਿਆਪਕ ਹੈ, ਇਸਲਈ ਮੈਂ ਸੰਸਕਰਣ ਲਈ VMware vSphere API ਸੰਦਰਭ ਦੀ ਸਿਫਾਰਸ਼ ਕਰ ਸਕਦਾ ਹਾਂ 5.5 и 6.0. ਹੋਰ ਮੌਜੂਦਾ ਸੰਸਕਰਣਾਂ ਲਈ, ਸਭ ਕੁਝ ਗੂਗਲ ਕੀਤਾ ਗਿਆ ਹੈ।

VIX API. ਹਾਈਪਰਵਾਈਜ਼ਰ ਦਾ ਕਾਲਾ ਜਾਦੂ, ਜਿਸ ਲਈ ਇੱਕ ਵੱਖਰਾ ਹੈ ਗਲਤੀ ਸੂਚੀ. VMware API ਹੋਸਟ 'ਤੇ ਫਾਈਲਾਂ ਨਾਲ ਨੈੱਟਵਰਕ 'ਤੇ ਉਹਨਾਂ ਨਾਲ ਕਨੈਕਟ ਕੀਤੇ ਬਿਨਾਂ ਕੰਮ ਕਰਨ ਲਈ। ਇੱਕ ਆਖਰੀ ਸਹਾਰਾ ਵਿਕਲਪ ਜਦੋਂ ਤੁਹਾਨੂੰ ਇੱਕ ਮਸ਼ੀਨ ਵਿੱਚ ਇੱਕ ਫਾਈਲ ਰੱਖਣ ਦੀ ਜ਼ਰੂਰਤ ਹੁੰਦੀ ਹੈ ਜਿਸ ਨਾਲ ਕੋਈ ਵਧੀਆ ਸੰਚਾਰ ਚੈਨਲ ਨਹੀਂ ਹੁੰਦਾ. ਇਹ ਦਰਦ ਅਤੇ ਦੁੱਖ ਹੈ ਜੇਕਰ ਫਾਈਲ ਵੱਡੀ ਹੈ ਅਤੇ ਹੋਸਟ ਲੋਡ ਕੀਤਾ ਗਿਆ ਹੈ. ਪਰ ਇੱਥੇ ਇਹ ਨਿਯਮ ਕੰਮ ਕਰਦਾ ਹੈ ਕਿ 56,6 Kb/s ਵੀ 0 Kb/s ਨਾਲੋਂ ਬਿਹਤਰ ਹੈ। ਹਾਈਪਰ-ਵੀ ਵਿੱਚ, ਇਸ ਚੀਜ਼ ਨੂੰ ਪਾਵਰਸ਼ੇਲ ਡਾਇਰੈਕਟ ਕਿਹਾ ਜਾਂਦਾ ਹੈ। ਪਰ ਇਹ ਸਿਰਫ ਪਹਿਲਾਂ ਸੀ

vSpehere ਵੈੱਬ ਸੇਵਾਵਾਂ API vSphere 6.0 ਤੋਂ ਸ਼ੁਰੂ ਕਰਦੇ ਹੋਏ (ਲਗਭਗ, ਕਿਉਂਕਿ ਇਹ API ਪਹਿਲੀ ਵਾਰ ਸੰਸਕਰਣ 5.5 'ਤੇ ਪੇਸ਼ ਕੀਤਾ ਗਿਆ ਸੀ) ਇਸਦੀ ਵਰਤੋਂ ਗੈਸਟ ਮਸ਼ੀਨਾਂ ਨਾਲ ਕੰਮ ਕਰਨ ਲਈ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਅਤੇ ਲਗਭਗ ਹਰ ਜਗ੍ਹਾ VIX ਨੂੰ ਬਦਲ ਦਿੱਤਾ ਗਿਆ ਹੈ। ਵਾਸਤਵ ਵਿੱਚ, ਇਹ vSphere ਦੇ ਪ੍ਰਬੰਧਨ ਲਈ ਇੱਕ ਹੋਰ API ਹੈ. ਉਹਨਾਂ ਲਈ ਜੋ ਦਿਲਚਸਪੀ ਰੱਖਦੇ ਹਨ, ਮੈਂ ਅਧਿਐਨ ਕਰਨ ਦੀ ਸਿਫਾਰਸ਼ ਕਰਦਾ ਹਾਂ ਮਹਾਨ ਮੈਨੁਅਲ 

ਵੀ.ਡੀ.ਡੀ.ਕੇ (ਵਰਚੁਅਲ ਡਿਸਕ ਡਿਵੈਲਪਮੈਂਟ ਕਿੱਟ)। ਲਾਇਬ੍ਰੇਰੀ, ਜਿਸ 'ਤੇ ਅੰਸ਼ਕ ਤੌਰ 'ਤੇ ਚਰਚਾ ਕੀਤੀ ਗਈ ਲੇਖ. ਵਰਚੁਅਲ ਡਿਸਕਾਂ ਨੂੰ ਪੜ੍ਹਨ ਲਈ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ। ਇੱਕ ਵਾਰ ਇਹ VIX ਦਾ ਹਿੱਸਾ ਸੀ, ਪਰ ਸਮੇਂ ਦੇ ਨਾਲ ਇਸਨੂੰ ਇੱਕ ਵੱਖਰੇ ਉਤਪਾਦ ਵਿੱਚ ਤਬਦੀਲ ਕਰ ਦਿੱਤਾ ਗਿਆ। ਪਰ ਇੱਕ ਵਾਰਸ ਦੇ ਰੂਪ ਵਿੱਚ, ਇਹ VIX ਵਾਂਗ ਹੀ ਗਲਤੀ ਕੋਡਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ। ਪਰ ਕਿਸੇ ਕਾਰਨ ਕਰਕੇ, SDK ਵਿੱਚ ਇਹਨਾਂ ਤਰੁੱਟੀਆਂ ਦਾ ਕੋਈ ਵਰਣਨ ਨਹੀਂ ਹੈ। ਇਸ ਲਈ, ਇਹ ਅਨੁਭਵੀ ਤੌਰ 'ਤੇ ਪਾਇਆ ਗਿਆ ਸੀ ਕਿ ਦੂਜੇ ਕੋਡਾਂ ਦੇ ਨਾਲ VDDK ਗਲਤੀਆਂ ਸਿਰਫ ਬਾਈਨਰੀ ਤੋਂ ਦਸ਼ਮਲਵ ਕੋਡ ਤੱਕ ਅਨੁਵਾਦ ਹਨ। ਇਸ ਵਿੱਚ ਦੋ ਭਾਗ ਹਨ - ਪਹਿਲਾ ਅੱਧ ਪ੍ਰਸੰਗ ਬਾਰੇ ਗੈਰ-ਦਸਤਾਵੇਜ਼ੀ ਜਾਣਕਾਰੀ ਹੈ, ਅਤੇ ਦੂਜਾ ਭਾਗ ਰਵਾਇਤੀ VIX / VDDK ਗਲਤੀਆਂ ਹਨ। ਉਦਾਹਰਨ ਲਈ, ਜੇ ਅਸੀਂ ਦੇਖਦੇ ਹਾਂ:

VDDK error: 21036749815809.Unknown error

ਫਿਰ ਅਸੀਂ ਦਲੇਰੀ ਨਾਲ ਇਸਨੂੰ ਹੈਕਸ ਵਿੱਚ ਬਦਲਦੇ ਹਾਂ ਅਤੇ 132200000001 ਪ੍ਰਾਪਤ ਕਰਦੇ ਹਾਂ। ਅਸੀਂ ਸਿਰਫ਼ 132200 ਦੀ ਅਣਜਾਣ ਸ਼ੁਰੂਆਤ ਨੂੰ ਰੱਦ ਕਰ ਦਿੰਦੇ ਹਾਂ, ਅਤੇ ਬਾਕੀ ਸਾਡਾ ਗਲਤੀ ਕੋਡ (VDDK 1: ਅਣਜਾਣ ਗਲਤੀ) ਹੋਵੇਗਾ। ਸਭ ਤੋਂ ਵੱਧ ਅਕਸਰ VDDK ਗਲਤੀਆਂ ਬਾਰੇ, ਹਾਲ ਹੀ ਵਿੱਚ ਇੱਕ ਵੱਖਰੀ ਸੀ ਲੇਖ.

ਹੁਣ ਆਓ ਦੇਖੀਏ ਵਿੰਡੋਜ਼.

ਇੱਥੇ, ਉਹ ਸਭ ਕੁਝ ਜੋ ਸਾਡੇ ਲਈ ਸਭ ਤੋਂ ਜ਼ਰੂਰੀ ਅਤੇ ਮਹੱਤਵਪੂਰਨ ਹੈ ਮਿਆਰ ਵਿੱਚ ਪਾਇਆ ਜਾ ਸਕਦਾ ਹੈ ਇਵੈਂਟ ਵਿਊਅਰ. ਪਰ ਇੱਥੇ ਇੱਕ ਕੈਚ ਹੈ: ਇੱਕ ਲੰਬੀ ਪਰੰਪਰਾ ਦੇ ਅਨੁਸਾਰ, ਵਿੰਡੋਜ਼ ਗਲਤੀ ਦੇ ਪੂਰੇ ਟੈਕਸਟ ਨੂੰ ਲੌਗ ਨਹੀਂ ਕਰਦਾ, ਪਰ ਸਿਰਫ ਇਸਦਾ ਨੰਬਰ. ਉਦਾਹਰਨ ਲਈ, ਗਲਤੀ 5 ਹੈ "ਪਹੁੰਚ ਇਨਕਾਰ", ਅਤੇ 1722 ਹੈ "ਆਰਪੀਸੀ ਸਰਵਰ ਅਣਉਪਲਬਧ ਹੈ", ਅਤੇ 10060 "ਕਨੈਕਸ਼ਨ ਦਾ ਸਮਾਂ ਸਮਾਪਤ" ਹੈ। ਬੇਸ਼ੱਕ, ਇਹ ਬਹੁਤ ਵਧੀਆ ਹੈ ਜੇਕਰ ਤੁਹਾਨੂੰ ਸਭ ਤੋਂ ਮਸ਼ਹੂਰ ਲੋਕਾਂ ਨੂੰ ਯਾਦ ਹੈ, ਪਰ ਹੁਣ ਤੱਕ ਅਣਦੇਖੇ ਲੋਕਾਂ ਬਾਰੇ ਕੀ? 

ਅਤੇ ਇਸ ਲਈ ਕਿ ਜੀਵਨ ਬਿਲਕੁਲ ਸ਼ਹਿਦ ਵਰਗਾ ਨਹੀਂ ਲੱਗਦਾ, ਗਲਤੀਆਂ ਵੀ ਹੈਕਸਾਡੈਸੀਮਲ ਰੂਪ ਵਿੱਚ, 0x8007 ਅਗੇਤਰ ਦੇ ਨਾਲ ਸਟੋਰ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ। ਉਦਾਹਰਨ ਲਈ, 0x8007000e ਅਸਲ ਵਿੱਚ 14, ਮੈਮੋਰੀ ਤੋਂ ਬਾਹਰ ਹੈ। ਅਜਿਹਾ ਕਿਉਂ ਅਤੇ ਕਿਸ ਲਈ ਕੀਤਾ ਗਿਆ, ਇਹ ਹਨੇਰੇ ਵਿੱਚ ਛਾਇਆ ਹੋਇਆ ਇੱਕ ਰਹੱਸ ਹੈ। ਹਾਲਾਂਕਿ, ਗਲਤੀਆਂ ਦੀ ਪੂਰੀ ਸੂਚੀ ਮੁਫ਼ਤ ਅਤੇ ਬਿਨਾਂ SMS ਤੋਂ ਡਾਊਨਲੋਡ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ devcenter.

ਤਰੀਕੇ ਨਾਲ, ਕਈ ਵਾਰ ਹੋਰ ਅਗੇਤਰ ਹੁੰਦੇ ਹਨ, ਨਾ ਕਿ ਸਿਰਫ਼ 0x8007। ਅਜਿਹੀ ਉਦਾਸ ਸਥਿਤੀ ਵਿੱਚ, HRESULT ("ਨਤੀਜਾ ਹੈਂਡਲ") ਨੂੰ ਸਮਝਣ ਲਈ, ਤੁਹਾਨੂੰ ਇਸ ਵਿੱਚ ਹੋਰ ਵੀ ਡੂੰਘਾਈ ਨਾਲ ਜਾਣ ਦੀ ਲੋੜ ਹੈ ਦਸਤਾਵੇਜ਼ ਡਿਵੈਲਪਰਾਂ ਲਈ. ਆਮ ਜ਼ਿੰਦਗੀ ਵਿੱਚ, ਮੈਂ ਤੁਹਾਨੂੰ ਅਜਿਹਾ ਕਰਨ ਦੀ ਸਲਾਹ ਨਹੀਂ ਦਿੰਦਾ, ਪਰ ਜੇ ਤੁਸੀਂ ਅਚਾਨਕ ਕੰਧ ਨਾਲ ਦਬਾ ਦਿੱਤਾ ਜਾਂ ਸਿਰਫ ਉਤਸੁਕ ਹੋ, ਤਾਂ ਹੁਣ ਤੁਸੀਂ ਜਾਣਦੇ ਹੋ ਕਿ ਕੀ ਕਰਨਾ ਹੈ।

ਪਰ ਮਾਈਕ੍ਰੋਸਾਫਟ ਦੇ ਕਾਮਰੇਡਾਂ ਨੇ ਸਾਡੇ 'ਤੇ ਥੋੜਾ ਜਿਹਾ ਤਰਸ ਲਿਆ ਅਤੇ ਦੁਨੀਆ ਨੂੰ ਇੱਕ ਉਪਯੋਗਤਾ ਦਿਖਾਈ ERR. ਇਹ ਕੰਸੋਲ ਖੁਸ਼ੀ ਦਾ ਇੱਕ ਛੋਟਾ ਜਿਹਾ ਟੁਕੜਾ ਹੈ ਜੋ ਗੂਗਲ ਦੀ ਵਰਤੋਂ ਕੀਤੇ ਬਿਨਾਂ ਗਲਤੀ ਕੋਡਾਂ ਦਾ ਮਨੁੱਖੀ ਵਿੱਚ ਅਨੁਵਾਦ ਕਰ ਸਕਦਾ ਹੈ। ਇਹ ਇਸ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰਦਾ ਹੈ।

C:UsersrootDesktop>err.exe 0x54f
# for hex 0x54f / decimal 1359
  ERROR_INTERNAL_ERROR                                           winerror.h
# An internal error occurred.
# as an HRESULT: Severity: SUCCESS (0), FACILITY_NULL (0x0), Code 0x54f
# for hex 0x54f / decimal 1359
  ERROR_INTERNAL_ERROR                                           winerror.h
# An internal error occurred.
# 2 matches found for "0x54f"

ਇੱਕ ਜਾਇਜ਼ ਸਵਾਲ ਉੱਠਦਾ ਹੈ: ਅਸੀਂ ਲੌਗਸ ਨੂੰ ਤੁਰੰਤ ਡੀਕ੍ਰਿਪਸ਼ਨ ਕਿਉਂ ਨਹੀਂ ਲਿਖਦੇ, ਪਰ ਇਹਨਾਂ ਰਹੱਸਮਈ ਕੋਡਾਂ ਨੂੰ ਛੱਡ ਦਿੰਦੇ ਹਾਂ? ਜਵਾਬ ਤੀਜੀ-ਧਿਰ ਦੀਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਵਿੱਚ ਹੈ। ਜਦੋਂ ਤੁਸੀਂ ਕੁਝ WinAPI ਕਾਲ ਆਪਣੇ ਆਪ ਨੂੰ ਖਿੱਚਦੇ ਹੋ, ਤਾਂ ਇਸਦੇ ਜਵਾਬ ਨੂੰ ਸਮਝਣਾ ਮੁਸ਼ਕਲ ਨਹੀਂ ਹੁੰਦਾ, ਕਿਉਂਕਿ ਇਸਦੇ ਲਈ ਇੱਕ ਵਿਸ਼ੇਸ਼ WinAPI ਕਾਲ ਵੀ ਹੈ। ਪਰ ਜਿਵੇਂ ਕਿ ਪਹਿਲਾਂ ਹੀ ਦੱਸਿਆ ਗਿਆ ਹੈ, ਹਰ ਚੀਜ਼ ਜੋ ਸਾਡੇ ਕੋਲ ਜਵਾਬਾਂ ਵਿੱਚ ਆਉਂਦੀ ਹੈ, ਸਾਡੇ ਲੌਗਸ ਵਿੱਚ ਆਉਂਦੀ ਹੈ. ਅਤੇ ਇੱਥੇ, ਇਸ ਨੂੰ ਡੀਕ੍ਰਿਪਟ ਕਰਨ ਲਈ, ਕਿਸੇ ਨੂੰ ਲਗਾਤਾਰ ਚੇਤਨਾ ਦੀ ਇਸ ਧਾਰਾ ਦੀ ਨਿਗਰਾਨੀ ਕਰਨੀ ਪਵੇਗੀ, ਇਸ ਵਿੱਚੋਂ ਵਿੰਡੋਜ਼ ਦੀਆਂ ਗਲਤੀਆਂ ਵਾਲੇ ਟੁਕੜੇ ਕੱਢਣੇ ਪੈਣਗੇ, ਉਹਨਾਂ ਨੂੰ ਡੀਕ੍ਰਿਪਟ ਕਰੋ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਵਾਪਸ ਪੇਸਟ ਕਰੋ. ਆਓ ਈਮਾਨਦਾਰ ਬਣੀਏ, ਸਭ ਤੋਂ ਦਿਲਚਸਪ ਗਤੀਵਿਧੀ ਨਹੀਂ.

ਵਿੰਡੋਜ਼ ਫਾਈਲ ਮੈਨੇਜਮੈਂਟ API ਫਾਈਲਾਂ ਨਾਲ ਕੰਮ ਕਰਦੇ ਸਮੇਂ ਹਰ ਸੰਭਵ ਤਰੀਕੇ ਨਾਲ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ। ਫਾਈਲਾਂ ਬਣਾਉਣਾ, ਮਿਟਾਉਣਾ, ਲਿਖਣ ਲਈ ਖੋਲ੍ਹਣਾ, ਗੁਣਾਂ ਨਾਲ ਕੰਮ ਕਰਨਾ, ਅਤੇ ਹੋਰ ਬਹੁਤ ਕੁਝ।

ਉੱਪਰ ਜ਼ਿਕਰ ਕੀਤਾ ਪਾਵਰਸ਼ੇਲ ਡਾਇਰੈਕਟ ਹਾਈਪਰ-ਵੀ ਸੰਸਾਰ ਵਿੱਚ VIX API ਦੇ ਐਨਾਲਾਗ ਵਜੋਂ। ਬਦਕਿਸਮਤੀ ਨਾਲ, ਇੰਨਾ ਲਚਕਦਾਰ ਨਹੀਂ: ਕਾਰਜਸ਼ੀਲਤਾ 'ਤੇ ਬਹੁਤ ਸਾਰੀਆਂ ਪਾਬੰਦੀਆਂ, ਇਹ ਮੇਜ਼ਬਾਨ ਦੇ ਹਰ ਸੰਸਕਰਣ ਨਾਲ ਕੰਮ ਨਹੀਂ ਕਰਦਾ ਅਤੇ ਨਾ ਹੀ ਸਾਰੇ ਮਹਿਮਾਨਾਂ ਨਾਲ।

ਸੀ.ਪੀ.ਆਰ. (ਰਿਮੋਟ ਪ੍ਰੋਸੀਜ਼ਰ ਕਾਲ) ਮੈਨੂੰ ਨਹੀਂ ਲੱਗਦਾ ਕਿ ਵਿੰਡੋਜ਼ ਨਾਲ ਕੰਮ ਕਰਨ ਵਾਲਾ ਕੋਈ ਵੀ ਵਿਅਕਤੀ ਨਹੀਂ ਹੈ ਜਿਸ ਨੇ RPC-ਸੰਬੰਧੀ ਤਰੁੱਟੀਆਂ ਨਹੀਂ ਦੇਖੀਆਂ ਹਨ। ਪ੍ਰਸਿੱਧ ਗਲਤ ਧਾਰਨਾ ਦੇ ਬਾਵਜੂਦ, ਇਹ ਇੱਕ ਸਿੰਗਲ ਪ੍ਰੋਟੋਕੋਲ ਨਹੀਂ ਹੈ, ਪਰ ਕੋਈ ਵੀ ਕਲਾਇੰਟ-ਸਰਵਰ ਪ੍ਰੋਟੋਕੋਲ ਹੈ ਜੋ ਕਈ ਮਾਪਦੰਡਾਂ ਨੂੰ ਸੰਤੁਸ਼ਟ ਕਰਦਾ ਹੈ। ਹਾਲਾਂਕਿ, ਜੇਕਰ ਸਾਡੇ ਲੌਗਸ ਵਿੱਚ ਇੱਕ RPC ਗਲਤੀ ਹੈ, ਤਾਂ 90% ਵਾਰ ਇਹ Microsoft RPC ਤੋਂ ਇੱਕ ਗਲਤੀ ਹੋਵੇਗੀ, ਜੋ ਕਿ DCOM (ਡਿਸਟ੍ਰੀਬਿਊਟਡ ਕੰਪੋਨੈਂਟ ਆਬਜੈਕਟ ਮਾਡਲ) ਦਾ ਹਿੱਸਾ ਹੈ। ਤੁਸੀਂ ਨੈੱਟ 'ਤੇ ਇਸ ਵਿਸ਼ੇ 'ਤੇ ਬਹੁਤ ਸਾਰੇ ਦਸਤਾਵੇਜ਼ ਲੱਭ ਸਕਦੇ ਹੋ, ਪਰ ਇਸਦਾ ਵੱਡਾ ਹਿੱਸਾ ਬਹੁਤ ਪੁਰਾਣਾ ਹੈ। ਪਰ ਜੇ ਵਿਸ਼ੇ ਦਾ ਅਧਿਐਨ ਕਰਨ ਦੀ ਤੀਬਰ ਇੱਛਾ ਹੈ, ਤਾਂ ਮੈਂ ਲੇਖਾਂ ਦੀ ਸਿਫਾਰਸ਼ ਕਰ ਸਕਦਾ ਹਾਂ RPC ਕੀ ਹੈ?, ਕਿਵੇਂ ਆਰਪੀਸੀ ਵਰਕਸ ਅਤੇ ਲੰਬੀ ਸੂਚੀ RPC ਤਰੁੱਟੀਆਂ.

ਸਾਡੇ ਲੌਗਸ ਵਿੱਚ RPC ਤਰੁੱਟੀਆਂ ਦੇ ਮੁੱਖ ਕਾਰਨ VBR ਕੰਪੋਨੈਂਟਸ (ਸਰਵਰ > ਪ੍ਰੌਕਸੀ, ਉਦਾਹਰਨ ਲਈ) ਵਿਚਕਾਰ ਸੰਚਾਰ ਕਰਨ ਦੀਆਂ ਅਸਫਲ ਕੋਸ਼ਿਸ਼ਾਂ ਅਤੇ ਅਕਸਰ ਸੰਚਾਰ ਸਮੱਸਿਆਵਾਂ ਦੇ ਕਾਰਨ ਹਨ।

ਸਭ ਸਿਖਰ ਦੇ ਵਿਚਕਾਰ ਸਭ ਤੋਂ ਉੱਪਰ ਇੱਕ ਗਲਤੀ ਹੈ RPC ਸਰਵਰ ਅਣਉਪਲਬਧ ਹੈ (1722)। ਸਧਾਰਨ ਸ਼ਬਦਾਂ ਵਿੱਚ, ਕਲਾਇੰਟ ਸਰਵਰ ਨਾਲ ਇੱਕ ਕੁਨੈਕਸ਼ਨ ਸਥਾਪਤ ਨਹੀਂ ਕਰ ਸਕਿਆ। ਕਿਵੇਂ ਅਤੇ ਕਿਉਂ - ਇੱਥੇ ਕੋਈ ਇੱਕਲਾ ਜਵਾਬ ਨਹੀਂ ਹੈ, ਪਰ ਆਮ ਤੌਰ 'ਤੇ ਇਹ ਪ੍ਰਮਾਣਿਕਤਾ ਜਾਂ ਪੋਰਟ 135 ਤੱਕ ਨੈੱਟਵਰਕ ਪਹੁੰਚ ਨਾਲ ਇੱਕ ਸਮੱਸਿਆ ਹੈ। ਬਾਅਦ ਵਾਲਾ ਗਤੀਸ਼ੀਲ ਪੋਰਟ ਅਸਾਈਨਮੈਂਟ ਵਾਲੇ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਲਈ ਖਾਸ ਹੈ। ਇਸ ਵਿਸ਼ੇ 'ਤੇ, ਵੀ ਹੈ ਵੱਖਰਾ HF. ਅਤੇ ਮਾਈਕ੍ਰੋਸਾਫਟ ਕੋਲ ਹੈ ਵਿਸ਼ਾਲ ਗਾਈਡ ਅਸਫਲਤਾ ਦਾ ਕਾਰਨ ਲੱਭਣ ਲਈ.

ਦੂਜੀ ਸਭ ਤੋਂ ਮਸ਼ਹੂਰ ਗਲਤੀ: ਐਂਡਪੁਆਇੰਟ ਮੈਪਰ (1753) ਤੋਂ ਕੋਈ ਹੋਰ ਐਂਡਪੁਆਇੰਟ ਉਪਲਬਧ ਨਹੀਂ ਹਨ। RPC ਕਲਾਇੰਟ ਜਾਂ ਸਰਵਰ ਆਪਣੇ ਆਪ ਨੂੰ ਇੱਕ ਪੋਰਟ ਨਿਰਧਾਰਤ ਕਰਨ ਵਿੱਚ ਅਸਫਲ ਰਿਹਾ। ਆਮ ਤੌਰ 'ਤੇ ਉਦੋਂ ਵਾਪਰਦਾ ਹੈ ਜਦੋਂ ਸਰਵਰ (ਸਾਡੇ ਕੇਸ ਵਿੱਚ, ਗੈਸਟ ਮਸ਼ੀਨ) ਨੂੰ ਇੱਕ ਤੰਗ ਸੀਮਾ ਤੋਂ ਪੋਰਟਾਂ ਨੂੰ ਗਤੀਸ਼ੀਲ ਤੌਰ 'ਤੇ ਨਿਰਧਾਰਤ ਕਰਨ ਲਈ ਸੰਰਚਿਤ ਕੀਤਾ ਗਿਆ ਹੈ ਜੋ ਖਤਮ ਹੋ ਗਈ ਹੈ। ਅਤੇ ਜੇਕਰ ਤੁਸੀਂ ਕਲਾਇੰਟ ਸਾਈਡ (ਸਾਡੇ ਕੇਸ ਵਿੱਚ, VBR ਸਰਵਰ) ਤੋਂ ਲੌਗਇਨ ਕਰਦੇ ਹੋ, ਤਾਂ ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਸਾਡਾ VeeamVssAgent ਜਾਂ ਤਾਂ ਸ਼ੁਰੂ ਨਹੀਂ ਹੋਇਆ ਜਾਂ RPC ਇੰਟਰਫੇਸ ਵਜੋਂ ਰਜਿਸਟਰ ਨਹੀਂ ਹੋਇਆ ਹੈ। ਇਸ ਵਿਸ਼ੇ 'ਤੇ ਵੀ ਹੈ ਵੱਖਰਾ HF.

ਖੈਰ, ਚੋਟੀ ਦੀਆਂ 3 RPC ਗਲਤੀਆਂ ਨੂੰ ਪੂਰਾ ਕਰਨ ਲਈ, ਆਓ ਯਾਦ ਕਰੀਏ RPC ਫੰਕਸ਼ਨ ਕਾਲ ਅਸਫਲ (1726)। ਦਿਸਦਾ ਹੈ ਜੇਕਰ ਕੁਨੈਕਸ਼ਨ ਸਥਾਪਿਤ ਹੋ ਗਿਆ ਹੈ, ਪਰ RPC ਬੇਨਤੀਆਂ 'ਤੇ ਕਾਰਵਾਈ ਨਹੀਂ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਉਦਾਹਰਨ ਲਈ, ਅਸੀਂ VSS ਦੀ ਸਥਿਤੀ ਬਾਰੇ ਜਾਣਕਾਰੀ ਦੀ ਬੇਨਤੀ ਕਰਦੇ ਹਾਂ (ਅਚਾਨਕ ਇਸ ਸਮੇਂ ਉੱਥੇ ਇੱਕ ਸ਼ੈਡੋ ਮਾਈਨ ਬਣਾਇਆ ਜਾ ਰਿਹਾ ਹੈ, ਅਤੇ ਅਸੀਂ ਚੜ੍ਹਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਹੇ ਹਾਂ), ਅਤੇ ਸਾਡੇ ਜਵਾਬ ਵਿੱਚ, ਚੁੱਪ ਅਤੇ ਅਣਡਿੱਠਾ.

ਵਿੰਡੋਜ਼ ਟੇਪ ਬੈਕਅੱਪ API ਟੇਪ ਲਾਇਬ੍ਰੇਰੀਆਂ ਜਾਂ ਡਰਾਈਵਾਂ ਨਾਲ ਕੰਮ ਕਰਨ ਦੀ ਲੋੜ ਹੈ। ਜਿਵੇਂ ਕਿ ਮੈਂ ਸ਼ੁਰੂ ਵਿੱਚ ਜ਼ਿਕਰ ਕੀਤਾ ਸੀ: ਸਾਨੂੰ ਆਪਣੇ ਡਰਾਈਵਰਾਂ ਨੂੰ ਲਿਖਣ ਵਿੱਚ ਕੋਈ ਖੁਸ਼ੀ ਨਹੀਂ ਹੈ ਅਤੇ ਫਿਰ ਹਰੇਕ ਡਿਵਾਈਸ ਦੇ ਸਹਾਰੇ ਦੁੱਖ ਝੱਲਣਾ ਪੈਂਦਾ ਹੈ. ਇਸ ਲਈ, ਵਿਮ ਦਾ ਆਪਣਾ ਕੋਈ ਡਰਾਈਵਰ ਨਹੀਂ ਹੈ। ਇੱਕ ਮਿਆਰੀ API ਦੁਆਰਾ, ਜਿਸਦਾ ਸਮਰਥਨ ਖੁਦ ਹਾਰਡਵੇਅਰ ਵਿਕਰੇਤਾ ਦੁਆਰਾ ਲਾਗੂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਇੰਨਾ ਜ਼ਿਆਦਾ ਲਾਜ਼ੀਕਲ, ਠੀਕ ਹੈ?

SMB / CIFS ਆਦਤ ਤੋਂ ਬਾਹਰ, ਹਰ ਕੋਈ ਉਹਨਾਂ ਨੂੰ ਨਾਲ-ਨਾਲ ਲਿਖਦਾ ਹੈ, ਹਾਲਾਂਕਿ ਹਰ ਕੋਈ ਯਾਦ ਨਹੀਂ ਰੱਖਦਾ ਕਿ CIFS (ਕਾਮਨ ਇੰਟਰਨੈਟ ਫਾਈਲ ਸਿਸਟਮ) SMB (ਸਰਵਰ ਮੈਸੇਜ ਬਲਾਕ) ਦਾ ਸਿਰਫ਼ ਇੱਕ ਨਿੱਜੀ ਸੰਸਕਰਣ ਹੈ। ਇਸ ਲਈ ਇਹਨਾਂ ਧਾਰਨਾਵਾਂ ਨੂੰ ਸਾਧਾਰਨ ਬਣਾਉਣ ਵਿੱਚ ਕੁਝ ਵੀ ਗਲਤ ਨਹੀਂ ਹੈ। ਸਾਂਬਾ ਪਹਿਲਾਂ ਹੀ ਇੱਕ ਲੀਨਕਸਯੂਨਿਕਸ ਲਾਗੂਕਰਨ ਹੈ, ਅਤੇ ਇਸ ਦੀਆਂ ਆਪਣੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਹਨ, ਪਰ ਮੈਂ ਇਸ ਨੂੰ ਛੱਡ ਦਿੰਦਾ ਹਾਂ। ਇੱਥੇ ਕੀ ਮਹੱਤਵਪੂਰਨ ਹੈ: ਜਦੋਂ ਵੀਮ UNC ਮਾਰਗ (ਸਰਵਰਡਾਇਰੈਕਟਰੀ) ਵਿੱਚ ਕੁਝ ਲਿਖਣ ਲਈ ਕਹਿੰਦਾ ਹੈ, ਤਾਂ ਸਰਵਰ ਫਾਈਲ ਸਿਸਟਮ ਡਰਾਈਵਰਾਂ ਦੀ ਲੜੀ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ, ਜਿਸ ਵਿੱਚ mup ਅਤੇ mrxsmb ਵੀ ਸ਼ਾਮਲ ਹੈ, ਬਾਲ ਨੂੰ ਲਿਖਣ ਲਈ। ਇਸ ਅਨੁਸਾਰ, ਇਹ ਡਰਾਈਵਰ ਵੀ ਗਲਤੀ ਪੈਦਾ ਕਰਨਗੇ.

ਬਿਨਾਂ ਨਹੀਂ ਕਰ ਸਕਦਾ ਵਿਨਸੌਕ API. ਜੇਕਰ ਨੈੱਟਵਰਕ ਉੱਤੇ ਕੁਝ ਕਰਨ ਦੀ ਲੋੜ ਹੈ, ਤਾਂ VBR ਵਿੰਡੋਜ਼ ਸਾਕੇਟ API ਦੁਆਰਾ ਕੰਮ ਕਰਦਾ ਹੈ, ਜਿਸਨੂੰ ਵਿਨਸੌਕ ਵਜੋਂ ਜਾਣਿਆ ਜਾਂਦਾ ਹੈ। ਇਸ ਲਈ ਜੇਕਰ ਅਸੀਂ ਲੌਗ ਵਿੱਚ IP:ਪੋਰਟ ਦਾ ਇੱਕ ਸਮੂਹ ਦੇਖਦੇ ਹਾਂ, ਤਾਂ ਇਹ ਹੈ। ਅਧਿਕਾਰਤ ਦਸਤਾਵੇਜ਼ਾਂ ਵਿੱਚ ਸੰਭਵ ਦੀ ਇੱਕ ਚੰਗੀ ਸੂਚੀ ਹੈ ਗ਼ਲਤੀਆਂ.

ਉੱਪਰ ਜ਼ਿਕਰ ਕੀਤਾ WMI (ਵਿੰਡੋਜ਼ ਮੈਨੇਜਮੈਂਟ ਇੰਸਟਰੂਮੈਂਟੇਸ਼ਨ) ਵਿੰਡੋਜ਼ ਦੀ ਦੁਨੀਆ ਵਿੱਚ ਹਰ ਚੀਜ਼ ਅਤੇ ਹਰੇਕ ਦੇ ਪ੍ਰਬੰਧਨ ਲਈ ਸਰਵਸ਼ਕਤੀਮਾਨ API ਦੀ ਇੱਕ ਕਿਸਮ ਹੈ। ਉਦਾਹਰਨ ਲਈ, ਹਾਈਪਰ-ਵੀ ਨਾਲ ਕੰਮ ਕਰਦੇ ਸਮੇਂ, ਹੋਸਟ ਨੂੰ ਲਗਭਗ ਸਾਰੀਆਂ ਬੇਨਤੀਆਂ ਇਸ ਵਿੱਚੋਂ ਲੰਘਦੀਆਂ ਹਨ। ਇੱਕ ਸ਼ਬਦ ਵਿੱਚ, ਚੀਜ਼ ਆਪਣੀ ਸਮਰੱਥਾ ਵਿੱਚ ਬਿਲਕੁਲ ਅਟੱਲ ਅਤੇ ਬਹੁਤ ਸ਼ਕਤੀਸ਼ਾਲੀ ਹੈ. ਇਹ ਪਤਾ ਲਗਾਉਣ ਵਿੱਚ ਮਦਦ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਵਿੱਚ ਕਿ ਕਿੱਥੇ ਅਤੇ ਕੀ ਟੁੱਟਿਆ ਹੈ, ਬਿਲਟ-ਇਨ WBEMtest.exe ਟੂਲ ਬਹੁਤ ਮਦਦ ਕਰਦਾ ਹੈ।

ਅਤੇ ਸੂਚੀ ਵਿੱਚ ਆਖਰੀ, ਪਰ ਕਿਸੇ ਵੀ ਤਰ੍ਹਾਂ ਘੱਟ ਤੋਂ ਘੱਟ ਮਹੱਤਵ ਵਿੱਚ - VSS (ਵਾਲੀਅਮ ਸ਼ੈਡੋ ਸਟੋਰੇਜ਼)। ਇਹ ਵਿਸ਼ਾ ਓਨਾ ਹੀ ਅਮੁੱਕ ਅਤੇ ਰਹੱਸਮਈ ਹੈ ਜਿੰਨਾ ਇਸ 'ਤੇ ਦਸਤਾਵੇਜ਼ੀ ਤੌਰ 'ਤੇ ਲਿਖਿਆ ਗਿਆ ਹੈ। ਸ਼ੈਡੋ ਕਾਪੀ ਨੂੰ ਇੱਕ ਵਿਸ਼ੇਸ਼ ਕਿਸਮ ਦੇ ਸਨੈਪਸ਼ਾਟ ਵਜੋਂ ਸਮਝਿਆ ਜਾਂਦਾ ਹੈ, ਜੋ ਅਸਲ ਵਿੱਚ ਇਹ ਹੈ। ਉਸ ਦਾ ਧੰਨਵਾਦ, ਤੁਸੀਂ VMware ਵਿੱਚ ਐਪਲੀਕੇਸ਼ਨ-ਇਕਸਾਰ ਬੈਕਅੱਪ ਬਣਾ ਸਕਦੇ ਹੋ, ਅਤੇ ਹਾਈਪਰ-V ਵਿੱਚ ਲਗਭਗ ਹਰ ਚੀਜ਼. ਮੇਰੇ ਕੋਲ VSS 'ਤੇ ਕੁਝ ਨਿਚੋੜ ਦੇ ਨਾਲ ਇੱਕ ਵੱਖਰਾ ਲੇਖ ਬਣਾਉਣ ਦੀ ਯੋਜਨਾ ਹੈ, ਪਰ ਹੁਣ ਲਈ ਤੁਸੀਂ ਪੜ੍ਹਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਸਕਦੇ ਹੋ ਇਹ ਵਰਣਨ. ਬਸ ਸਾਵਧਾਨ ਰਹੋ, ਕਿਉਂਕਿ. ਇੱਕ ਫਲੈਸ਼ ਵਿੱਚ VSS ਨੂੰ ਸਮਝਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਨਾਲ ਦਿਮਾਗ ਨੂੰ ਸੱਟ ਲੱਗ ਸਕਦੀ ਹੈ।

ਇਸ 'ਤੇ, ਸ਼ਾਇਦ, ਅਸੀਂ ਰੋਕ ਸਕਦੇ ਹਾਂ. ਮੈਂ ਸਭ ਤੋਂ ਬੁਨਿਆਦੀ ਚੀਜ਼ਾਂ ਨੂੰ ਸਮਝਾਉਣ ਦੇ ਕੰਮ ਨੂੰ ਪੂਰਾ ਕਰ ਲਿਆ ਹੈ, ਇਸ ਲਈ ਅਗਲੇ ਅਧਿਆਇ ਵਿੱਚ ਅਸੀਂ ਪਹਿਲਾਂ ਹੀ ਲੌਗਸ ਨੂੰ ਦੇਖਾਂਗੇ। ਪਰ ਜੇ ਤੁਹਾਡੇ ਕੋਈ ਸਵਾਲ ਹਨ, ਤਾਂ ਉਹਨਾਂ ਨੂੰ ਟਿੱਪਣੀਆਂ ਵਿੱਚ ਪੁੱਛਣ ਲਈ ਬੇਝਿਜਕ ਮਹਿਸੂਸ ਕਰੋ.

ਸਰੋਤ: www.habr.com