VMs prior to host agent installation not showing under virtual machines

[rmangion]

Hi,

I am running BE2014 as a media server runinng WS2012R2. My environment is as follows:

+ Blade Cluster -> 4 x Blades (hosts)

+SAN

+Virtual machines (approx. 10 VMs on each host) and their respective vhd's on the SAN

At present i have windows agents deployed directly to the VMs without Host integrity to backup the machines.

Today i pushed the agents on the Host machines as to start backing up the virtual machines through the host. To my surprise no virtual machines came up. Upon this discovery i created a test VM which instantly was discovered by BE. Is there some kind of procedure to be done when deploying Hyper-V host agents with existing virtual machines prior to the installation.

Did anybody came accross this issue ?

Thanks

[lmosla]

Are these backups going to be GRT backups?  If so, the VMware tools need to be installed prior to the agent.

also here is Best Practices: http://www.symantec.com/docs/HOWTO74443

[pkh]

Delete the VM's which show as real servers from the console and back them up using the host

[rmangion]

@ pkh- that does not reolve anything as i have VMs which did not have agents puched directly on the guest OS and still do not show under the host virtual machine selection list.

[rmangion]

Just to make the story a bit clearer, my intention is to start backing up the virtual machine on a VHD level once in a while and the only way to do it is to select the VM under the host selection list ..... Hence the preoccupation.

[VJware]

Right, so once a full backup with GRT completes successfully, the VMs will automatically appear under the Backup & Restore tab.

There isn't any need to manually add them unless you plan on backing them directly as a physical machine using the Remote Agent.

The only other time the VM will appear automatically under the Backup & Restore tab is if you install the Remote Agent inside the VM prior to the Hyper-V host backup job.

[Colin_Weaver]

That is expected behaviour - VM backups (either VMware or Hyper-V) are created via the host environment (for VMware this might include a VCenter server) and NOT via the individual virtual server objects. If you create via the individual VM server object it will be a RAWS backup of the content of your VHD instead of a VHD backup.

As well as for backups types, exactly which object you click on to start a restore depends on what type of restore you want to achieve.

- GRT restore would typically be via the VM server object

- full VM restore would typically be via the host server object

Note: there were some changes in BE 2014 that might mean there are more locations to initiate the different restores from than for both BE 2010 and BE 2012.

[rmangion]

I am assuming there was a misunderstanding somewhere, the issue is that although the agent can be installed on guest OS and can be backed up successfully without any issues, I wanted to start backing the virtual machine as a VHD on a scheduled basis. The issue i am getting is that although the agent was deployed/pushed succesfully directly as a RAWS and backed up succesfully too when i go to the host's selection list under virtual machines I only find one VM wcich was created after I installed the agent on the host. Below depicts the what I just said :

Having looked at this screen shot, one can see that only one VM is populating under the host, apart from the fact that there are a mixture of VMs that have RAWS deployed on them directly as if physical machines and also VMs which don't (as i do not require backups from them).

Hope i made myself clearer now.

regards

[VJware]

The VMs should populate automatically under the Hyper-V host even if the Remote Agent isn't installed in the VMs.

Is this Hyper-V host part of a cluster ?

Do the VMs appear properly under the host itself ? If yes, try restarting the Hyper-V management services and re-add the Hyper-V host under the Backup & Restore tab in BE.

[rmangion]

Yes the host is part of a cluster, the environemnt is as follows:

BladeCluster.contoso.com

and within the cluster are five blades :

BLADE 2 - 10 VMs (6 with agent / 4 no agent) 

BLADE 3 - 15 VMs (7 with agent / 8 no agent)

BLADE 4 - 13 VMs (11 with agent / 2 no agent)

BLADE 5 - 15 VMs (12 with agent / 3 no agent)

When you ask whether the VMs appear under the host properly, are you aksing within backup exec or in Hyper-V ? Within Hyper-V everything is as it's suppose to be.

[VJware]

Ok, when the VMs are part of a clustered Hyper-V setup, then add the virtual node/ip of the Hyper-V Cluster as a server resource under the Backup & Restore tab. Only, then will all VMs appear under the backup selections.

Do ensure RAWS is installed on every node and the BESA is an administrator under each node and within Hyper-V cluster manager as well.

[rmangion]

OK, the BladeCluster is managed by one of the hosts, so when the agent was deployed on the host the BladeCluster.contoso.com came showing in Backup & Restore tab.

I tried something else; created a new test VM and to my surprise it came showing under the virtual machines selection list. So to my logic it seems as if something is holding back the VMs from showing that reside on the host prior to the agent installation on the host. Any clues ...........

[VJware]

The VMs will show up under the Hyper-V node which owns it. Have attached a screenshot as to how the backup resource should appear as.

[rmangion]

This is what is showing under BladeCluster 

Under the host (Ex. SRV-BLADE05), although there are 15 VMs residing only one is showing; which was created after I installed the agent on the host.

Another thing I tried was to migrate the test VM i created earlier from one to another (only VM and not storage) and it suddenly cannot be seen under the host also. I am guessing that Backup Exec stops discovering VMs aftering migrating on the nodes/hosts.

[VJware · Accepted solution]

In my screenshot, HVNODE1 and HVNODE 2 are the 2 Hyper-V nodes, whereas hvcluster is the cluster name. If you check, it shows as Hyper-V HA Virtual Machines which I don't see in your screenshot. Secondly, if you check the icon beside the hvcluster, it shows a clustered icon whereas my hyper-v hosts show a single server icon.

You wouldn't see all the VMs if you expand any of your hosts (i.e. under BLADE 02, BLADE 03, BLADE04, BLADE05), but only under the Hyper-V cluster resource itself.

On a clustered setup, BE will not be able to discover the VMs on the passive nodes and which is why one has to add the cluster ip/name itself as the backup resource.

If you are indeed unable to view the VMs under the Hyper-V HA node (which is different from the regular Hyper-V node), then I would recommend to log a formal support case for us to review your setup.

[rmangion]

OK, got to work. Added the cluster by ip and all seems to be OK as the Cluster Shared volumes and Hyper-V HA Virtual Machines populated successfully

Cheers for the solution VJWare

[rmangion]

One last question, is it best to have VMs turned off when backing up the VHDs ?

[VJware]

It depends.

It depends if you are looking for GRT restore capability. (GRT restore refers to the capability of restoring individual files/folders from the VM backup) or If you are looking for backups to be disk-optimized. (Disk-optimization if applicable for the VM will backup only the used space).

[rmangion]

Can you please elaborate as to I did not get where is best to have VMs turned off and when they can stay switched on. Thanks

[VJware]

If you have VMs turned off, you miss out on at least 2 features.

1) GRT

This allows you restore single files, folders from the .vhd. If this is disabled, then you can restore only the complete VM, but not individual files and folders.

2) Disk Optimization

If your VM has been allocated 500GB of space, but only 100GB has been used and if the backup is taken when the VM is off, then the entire 500GB gets backed up. Whereas if the VM is on, only 100GB gets backed up.

In short, its always better to keep the VMs on during a backup (since that's why one invests in a virtual agent for online backups) than keeping them off.