New hardware found copying machine
-
samedi 5 avril 2008 07:16
Hi
I have my Hyper-v server 1 (RC0) with a guest on it. I turn off the guest, create a new virtual machine on my Hyper-v server 2 (RC0) and reuse the same vhd for the guest.
When the guest first boots on server 2, it detects a new network adapter, naming it Local area connection 2 and putting it on dhcp.
Why it does this way? Any other virtualization sw I used makes copying the machine from a host to the other a smooth operation.
Exporting and importig the machines correctly works, but thinking to disaster recovery this is not a viable solution.
What am I missing?
Thanks
Toutes les réponses
-
samedi 5 avril 2008 14:37
What is the operating system in the guest? Are the Hyper-V servers the same hardware? Do you have the virtual networks defined the same on both Hyper-V servers? What virtual network did you select for the virtual machine on both Hyper-V 1 and Hyper-V 2?
tgc
-
dimanche 6 avril 2008 14:25Hi!
The guest is Windows Server 2003 R2 with Integration components installed. The 2 Hyper-V servers have different network adapter (Intel/Broadcom). Same networks defined on both servers (a private one and an external one). The one selected is the one I created that is bound to an external network, the one to go on the Internet. After detecting the second network adapter all works fine, but I have to reconfigure it (being a AD+DNS server it needs static IPs).
Thanks -
lundi 7 avril 2008 15:17Modérateur
You have stated the reason for the difference. Your network cards are different in your hosts.
If you have previously work with VMware you have had a 100% emulated environment. That is the equivalent of running the Legacy Network Adapter within your VMs (no matter where your VM moves to the devices is always the same). This is the smae with Virtual Server and VirtualPC (they emulate devices as well).
Hyper-V is a different type of hypervisor - it uses a technique referred to as para-virtualization.
It can be thought of as more similar to the guest operating system running directly on the hardware.
Wikipedia says: "paravirtualization is a technique that presents a software interface to virtual machines that is similar but not identical to that of the underlying hardware"
As a result, it is a bit faster tha 100% emulation and also has some limitations.
But this is what you have run into - the hosts has different NICs and those different NICs wil be seen as different by the Guest OS.
In you case you may want to consider running your VM with the Legacy Network Adapter especially if you intend on moving it around a lot between hosts with different NICs.
-
lundi 7 avril 2008 15:23
I was thinking exactly that, but I was afraid of being right. This poses lots of limitations you must be aware before moving VMs in case of disaster.
I'll do some tests to see which is the difference in terms of performance between Legacy and Paravirtualized adapter.
Thanks for the important information.
Bye
-
lundi 7 avril 2008 17:43Propriétaire
Two statements here:
1) Whenever you create a new non-legacy network adapter and connect it to a virtual machine - it get's an identifying GUID. The behavior you are seeing is the same behavior that you would get if you shutdown your physical server and moved your physical netwirk adapter from one slot to another.
2) If you want to be prepared for 'disaster' scenarios - use VSS to backup your system regularly. This will address your concerns here.
Cheers,
Ben
-
mardi 8 avril 2008 15:15Modérateur
Ben has a good point.
The default Windows behavior when a new network adapter is installed is to set it to the default settings (DHCP and the like). This has been much the problem whenever trying to do a DR recovery onto physical hardware as all the devices would be redetected and we would have to dig through documentation trying to recall the configuration of (usually) the NIC.
The VSS based backup gives you to have a 'walk away' of a VM (VHD with its configuration) that you can mount on any Hyper-V host.
Another method (if you have to shut down your VM for maintenance anyway) is to periodically Export your VM - this also creates a walk away copy. And this actually imports properly between hosts in RC0.
-
mardi 8 avril 2008 15:35
Please help me a little bit more
With VSS backup you mean:
1) pause the vm
2) snap the volume with the vm on it
3) restart the VM
4) at this point I can copy the snapped machines or mount them directly.
Are those points right? Are we talking about the same thing?
If yes, I should not have the "New hardware detected" problem since guid are mantained somewhere? And so, how can I import my snapped machine on Virtual Server 2?
Thanks
-
mardi 8 avril 2008 15:47Propriétaire
Correct. When you restore the virtual machine from the VSS backup it will hookup the old configuration file - maintaining all the networking information.
Cheers,
Ben
-
mardi 8 avril 2008 15:52
Ok, please don't think I'm totally dumb, but HOW do I restore a virtual machine that was VSS/copied, given that the VM was not _exported_? Don't we have the problem that started this thred?
Thsnks again
-
mardi 8 avril 2008 15:55Propriétaire
If you backup the VM with VSS, you can restore the VM with VSS - and import / export is not involved.
Cheers,
Ben
-
mardi 8 avril 2008 16:01Modérateur
Do not think that snapshot is a method of backup or data recovery. It is strictly a tool to manage testing patches, service packs, software installs, etc.
VSS is the Microsoft Volume Snapshot Service provider - it is totally different than the snapshot function in the Hyper-V manager.
VSS is used by backup agents (BackupExec, Microsoft Backup, Data Protection Manager - for examples) to backup a running virtual machine and any VSS aware applicaton within that VM gets placed in a 'happy state' where everything is committed and it is ready to go.
What you walk away with from this process is a fully functional VM (somewhere in your backup storage) that can then be mounted.
Will it totally solve the GUID problem? It could as long as the NIC is never deleted and recreated in the settings - as the hardware info is in the config file.
If you don't want to mess around with backup software then you would perform an Export - as this also creates a fully functional VM - except your VM is powered off during the export.
The only way to do this with a running VM is using backup software that is VSS aware, run it at the Host level, and choose your VM (the config and VHD) and have the backup software manage it.
-
mardi 8 avril 2008 16:02
Probably I found the missing part: do you assume that VMs are hosted on an iSCSI/SAN backend?
But I was talking about Hyper-V Server 1 with VM1 on its local disk that fails. In this case I need Hyper-V server 2 to bring up VM1 starting froma file copy of the VSSed volume.
In any case, can you point me some forum thread about VSS backup a little bit more specific than "a backup that is done using VSS"?
Thnks again (and again)
Edit (ok to your previous post, I acknowledge the difference between VSS and Snapshots)
-
mardi 8 avril 2008 16:20Modérateur
I don't assume that the VM is located on any specific volume.
If you had iSCSI or a SAN then I would recommend setting up a cluster of two Hyper-V hosts and having your VM on shared storage and take advantage or what the marketing is calling High Availability.
Without that you have to use some sort of backup / restore type of operation.
There has been very little discussion about VSS and Hyper-V - I have looked around for some myself.
There is information on MSDN about programming to it, and there is general information about it.
Here is an overview of the reader / writer: http://support.microsoft.com/kb/889247
And here is a "how it works": http://technet2.microsoft.com/WindowsServer/en/library/2b0d2457-b7d8-42c3-b6c9-59c145b7765f1033.mspx?mfr=true
I hope it helps you develop a plan.
-
mardi 8 avril 2008 16:35
BrianEh wrote: I don't assume that the VM is located on any specific volume.
If you had iSCSI or a SAN then I would recommend setting up a cluster of two Hyper-V hosts and having your VM on shared storage and take advantage or what the marketing is calling High Availability.
Without that you have to use some sort of backup / restore type of operation.
There has been very little discussion about VSS and Hyper-V - I have looked around for some myself.
There is information on MSDN about programming to it, and there is general information about it.
Here is an overview of the reader / writer: http://support.microsoft.com/kb/889247
And here is a "how it works": http://technet2.microsoft.com/WindowsServer/en/library/2b0d2457-b7d8-42c3-b6c9-59c145b7765f1033.mspx?mfr=true
I hope it helps you develop a plan.
Ok, I've already setup a failover cluster with machines roaming on the nodes and it works. The only problem was to find a SCSI-3 persistent reservation compliant iSCSI backend (do you know of a free one?).
My way of using VSS is NOT via a backup software (DPM, BackupExec, ...) but usign some home made scripting. Specifically I use the four steps above
1) pause the vm
2) snap the volume with the vm on it
3) restart the VM
4) at this point I can copy the snapped machines _from the shadow copy to a different device_
I think we don't match on point 4). In my way of backupping VMs, I obtain the raw files of the machine on a SEPARATE device from the original (say a share or USB disk). Basically is the same that opening the console, pausing the machine, opening explorer to copy the files and then restaring the machine. The advantage is that machine stays offline for some seconds only.
The problem is that the copied files cannot be imported since the were not exported, and creating a new VM on the backup Hyper-v server using the copied vhd results in the problem that started this thread.
Basically what you mean is that I NEED a backup program and afford on its specific way to backup and restore machines. Am I right?
Thanks for the fast response
-
mardi 8 avril 2008 16:50Modérateur
When you perform your backup you need to grab the VHD and the configuration folder.
If your VM and Config files are in the same folder for example you have VMB and you have your default Virtual Machine Path set to X:\ you would get a folder VMB on X:\.
Just make sure that your VHD file is also located within that folder and you are good to target a single volume.
Otherwise, you can mimic the Export behavior by finding the Folder that contains the configurtaion of your VM (it might be under %programdata%\Microsoft\Windows\Hyper-V by default). Each configuration folder is given the name of the GUID of your VM.
Inside that GUID folder is the XML based config file - you can look for your VHD to figure out which one you need.
The Export creates the following structure:
\<vm name>
\Snapshots
\Virtual Hard Disks
\Virtual Machines
The GUID named config file would go into the Virtual Machines folder
The VHD(s) go into the Virtual Hard Disk folder
Etc.
Then when you import you copy to your run location and attach to the \<VM Name> folder. the import process looks for the config and VHD. Check that your path to your VHD is good and you should be good to go.
-
mardi 8 avril 2008 17:23
Well, this could be a practical way to do it.
I'll try it asap and let you know. I'm only curious about the fact that the machine copy I take is of a paused one, and export usually works with a shut down guest.
But, back to the topic, thi will lead to "New hardware found", that is the problem we solved some posts ago
Bye
.png)
