after migration vmdk to raw .net applicaitons stop working

[babmunir]

i have successfully migrated some windows web servers from vmware to promox using import option (adding esxi host in promox), everything looks fine but users start complaining their webservices stop working and throwing exception which was working fine on VMware. after some investigating i found lot of dotnet error System.IO.IOException generating in eventviewer like. it seems raw format is holding these files and does not allow to be changed by multiple processes. how to solve this as this is really annoying for us?

Category: Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware
EventId: 1
SpanId: 1398695b0107527d
TraceId: ca11144824ea720800b0d5d758a11722
ParentId: 01a7af66aa21e1bf
RequestId: 400004af-0004-7e00-b63f-84710c7967bb
RequestPath: /api/Auth/login

An unhandled exception has occurred while executing the request.

Exception:
System.IO.IOException: The process cannot access the file 'E:\EnrolAPI_Logs\Log-09-11-2025.txt' because it is being used by another process.
at Microsoft.Win32.SafeHandles.SafeFileHandle.CreateFile(String fullPath, FileMode mode, FileAccess access, FileShare share, FileOptions options)
at Microsoft.Win32.SafeHandles.SafeFileHandle.Open(String fullPath, FileMode mode, FileAccess access, FileShare share, FileOptions options, Int64 preallocationSize, Nullable`1 unixCreateMode)
at System.IO.Strategies.OSFileStreamStrategy..ctor(String path, FileMode mode, FileAccess access, FileShare share, FileOptions options, Int64 preallocationSize, Nullable`1 unixCreateMode)
at System.IO.Strategies.FileStreamHelpers.ChooseStrategyCore(String path, FileMode mode, FileAccess access, FileShare share, FileOptions options, Int64 preallocationSize, Nullable`1 unixCreateMode)
at System.IO.StreamWriter.ValidateArgsAndOpenPath(String path, Boolean append, Encoding encoding, Int32 bufferSize)
at System.IO.StreamWriter..ctor(String path, Boolean append)
at Entity.LoggerHelper.writelog(String message) in C:\Agents\INDICI-API-Agent\Dev\_work\8\s\DEV\Entity\LoggerHelper.cs:line 20
at DAL.Database.GetJwtCredentials(LoginModel model, String connectionString) in C:\DEV\DAL\Database.cs:line 25
at EnrolAPICore.Controllers.AuthController.login(LoginModel model) in C:\Dev\_work\8\s\DEV\EnrolAPICore\Controllers\AuthController.cs:line 53
at lambda_method3(Closure, Object, Object[])
at Microsoft.AspNetCore.Mvc.Infrastructure.ActionMethodExecutor.SyncActionResultExecutor.Execute(ActionContext actionContext, IActionResultTypeMapper mapper, ObjectMethodExecutor executor, Object controller, Object[] arguments)
at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.InvokeActionMethodAsync()
at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.Next(State& next, Scope& scope, Object& state, Boolean& isCompleted)
at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.InvokeNextActionFilterAsync()
--- End of stack trace from previous location ---
at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.Rethrow(ActionExecutedContextSealed context)
at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.Next(State& next, Scope& scope, Object& state, Boolean& isCompleted)
at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.InvokeInnerFilterAsync()
--- End of stack trace from previous location ---
at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeFilterPipelineAsync>g__Awaited|20_0(ResourceInvoker invoker, Task lastTask, State next, Scope scope, Object state, Boolean isCompleted)
at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeAsync>g__Awaited|17_0(ResourceInvoker invoker, Task task, IDisposable scope)
at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeAsync>g__Awaited|17_0(ResourceInvoker invoker, Task task, IDisposable scope)
at Microsoft.AspNetCore.Authorization.AuthorizationMiddleware.Invoke(HttpContext context)
at Microsoft.AspNetCore.Authentication.AuthenticationMiddleware.Invoke(HttpContext context)

 

[fiona]

Hi,
the disk format is completely transparent to the guest OS, i.e. Windows cannot possibly know what disk format QEMU uses for the VM or behave different just because of that. That is part of virtualization, for Windows the disk will look like a block device no matter whether if QEMU uses vmdk or raw.

How were the VMs migrated? Live or offline?

Please check why there are multiple processes accessing the file, this seems like an issue that's completely inside the guest, QEMU is not concerned with guest-internals like processes or file-systems.