Hyper-V VMs get hosed after backup
"Hosed" being the technical term. It seems that after either/or of 2 VMs on the host machine, after a backup, cannot start. It also appears that Backup Exec creates snapshots that don't get re-absorbed into the parent virtual disk. So I'll end up with a series of .avhdx's, and if I try to start that VM, it'll tell me there's an ID mismatch in the chain of virtual disks. Pretty much every single time after a backup. The exact error is: 'VSERVER' failed to start. Synthetic SCSI controller (Instance ID XXXXX): Failed to Power on with Error 'The chain of virtual hard disks is corrupted. There is a mismatch in the identifiers of the parent virtual hard disk and differencing disk'. There is a fix, using the Set-VHD command, but I can't keep doing that over and over again. Additionally, I'll get this error from Backup Exec itself: V-79-40960-38691 - Backup Exec cannot create a recovery checkpoint for the 'VSERVER' virtual machine. (Note: "Use snapshot technology" is checked). Any ideas where I can start looking to fix this? Backup Exec version 21.4, 1200.2536, Windows Server 2019 Thanks!BE failed to register recently-restored VM
I tried to restore a Hyper-V VM early this morning; and though the files were apparently restored, Backup Exec threw this error: Final error: 0xe0009645 - Backup Exec failed to register the virtual machine. See the job log and the Windows Event Viewer for more details. The virtual machine will not be available in the Hyper-V or Virtual Server Administration Console. The Windows Event Log shows this: An account failed to log on. Subject: Security ID: SYSTEM Account Name: SERVER$ Account Domain: DOMAIN Logon ID: 0x3E7 Logon Type: 5 Account For Which Logon Failed: Security ID: NULL SID Account Name: FE02C21F-063E-4593-831F-C10A3C52D958 Account Domain: NT VIRTUAL MACHINE Failure Information: Failure Reason: The user has not been granted the requested logon type at this machine. Status: 0xC000015B Sub Status: 0x0 I should note I had to restore a virtual machine before this one with zero problems. This 2nd one didn't want to restore properly for some reason. Using BE "Silver Perpetual" Version 21.4 on Windows Server 2019 Thanks!
Restored vhdx (Hypver-V) unable to mount
Hi all, I'm working for a small charity that has three WIndows Server 2019 hyper-v servers running a couple of VM's. I have forever incremental backup jobs running that seem to be running fine. However, after a successful restore, I've discovered that some, but not all, of the restored vhdx files have no partitions or no drive letters assigned when mounted. When right clicking on a restored vhdx file, one of three things happens depending on the vmdx. It mounts fine and assigns drive letters - that's the normal behavior that I'd expect. That does happen with many of the restored files, but not all unfortunately or Frequently I will get this error message Couldn't Mount File The disk image isn't initialized, contains partitions that aren't recognizable, or contains volumes that haven't been assigned drive letters. Please use the Disk Management snap-in to make sure that the disk, partitions, and volumes are in a usable state. then one of 2 things happens. Either 2a. In disk manager, I am asked to initialize the drive. After doing so there are no partitions on the drive, making it unusable. or 2b Sometimes I can se the partition(s) on a virtual drive in disk manager, but there's just no drive letter assigned. I still get the above "Couldn't mount file" message, but I don't need to initialize the drive, it just shows up in disk manager with no drive letters. This is pretty infrequent, it's usually 2a when I have a problem VHDX. When I can see the partitions, I can assign a drive letter, but I'm not sure what would happen if that VHDX file were used as a restoration that was to be spun up in Hyper-v Has anyone seen this before? I've not on any of the other servers I manage elsewhere with a very similar configuration. I should add that for each vm, all restored vhdx files for that vm will either all be okay, all have no partitions, or all have partitions but with no drive letters. I did create a NEW forever incremental backup for each of the 3 servers. I ran a new backup on one to test, then did a restore. 3 vm's restored fine where I could open the vhdx file, 3 gave me problem 2a above, and one gave me problem 2b. Any suggestions as to why this is happening and/or what I might be able to to stop it? No point in backing things up if the restores are unusable!! Thank you all
nbhypervtool.exe
Dear Veritas Enthusiasts, i would like to ask if anybody has additional information about the nbhypervtool.exe. i need to know what nbhypervtool.exe does in the back, does it only delete the snapshot, is it the same as using the powershell cmdlet remove-vmsnapshot or there is slightly different functionality. i am asking for these details in the context of some left snapshots of hyper-v virtual machines and the possible supported steps to remove old snapshots that netbackup left after the backup. thank you in advance!hyper-v backups are failing with status code 13 or 25 if the hyper-v virtual machines has a snapshot
any ideas are welcome on the following as the case we have with veritas is almost 2 months old without any progress: if the hyper-v virtual machine has a snapshot which was created from hyper-v or failover console, the backup of the vm fails with status code 13 or 25: 28.09.2020 18:57:27 - Error bpbrm (pid=145214) socket read failed: errno = 104 - Connection reset by peer 28.09.2020 18:57:27 - Error bptm (pid=147427) system call failed - Connection reset by peer (at ../child.c.1289) 28.09.2020 18:57:27 - Error bptm (pid=147427) unable to perform read from client socket, connection may have been broken 28.09.2020 18:57:28 - Error bptm (pid=147293) media manager terminated by parent process 28.09.2020 18:57:33 - Info xxxxx (pid=147293) StorageServer=PureDisk:xxxxxx; Report=PDDO Stats (multi-threaded stream used) for (xxxxx): scanned: 3 KB, CR sent: 0 KB, CR sent over FC: 0 KB, dedup: 100.0%, cache disabled 28.09.2020 18:57:35 - Error bpbrm (pid=145214) could not send server status message to client 28.09.2020 18:57:37 - Critical bpbrm (pid=145214) unexpected termination of client xxxxxx 28.09.2020 18:57:38 - Info bpbkar (pid=0) done. status: 13: file read failed 28.09.2020 19:00:15 - connecting 28.09.2020 19:00:16 - connected; connect time: 0:00:00 28.09.2020 19:00:22 - begin writing 28.09.2020 19:00:35 - end writing; write time: 0:00:13 file read failed (13) a workaround is to disable exclude deleted block and swap and paging files but this is not appropriate for us due to negative performance impact thank you all!
Choosing backup source for VMs on Hyper-V: Cluster or Node?
Greetings, all! Our site has a new 2-node Hyper-V cluster that will replace our well-aged VMware ESXi 5.5 cluster. So, I'll be using Backup Exec (v.20.5) on Hyper-V for the first time as we build new servers on and move existing servers (?) to the new system. Having pushed the Agent for Windows successfully to the two nodes, I noticed that the cluster appeared in the list as well and can be backed up along with its VMs. The VMs can be backed up by choosing the nodes, too, which makes me ask which method is the better one. I don't recall seeing a mention of the two possibilities or a recommendation in the Administrator's Guide. What can those of you with experience in such a situation recommend as a backup strategy? Thank you for sharing your collective wisdom!
Protecting Hyper-V Virtual Machines on SMB using Backup Exec 20.4
Starting from Windows Server 2012, virtual machines in Hyper-V can be configured to use Server Message Block (SMB) 3.0 file shares as storage just like local volumes. By using SMB shares, storages for Hyper-V can be converged and operating costs can be reduced. Additional advantages of Scale-out file servers include continuously available file services, automatic load balancing and easy management of servers. Deploying Hyper-V over SMB shares from Scale-out file servers is an ideal solution for Hyper-V.
