The answers are no, no, and yes, with the caveat that certain ESX patches may be required. Take a look at the compatibility matrix: http://www.vmware.com/pdf/srm_compat_matrix_4_0.pdf
Be extremely careful about doing SQL backups and restores! SRM treats its two databases (at primary and secondary sites) as one, and requires them to remain consistent. So, if you take a snapsh...
See more...
Be extremely careful about doing SQL backups and restores! SRM treats its two databases (at primary and secondary sites) as one, and requires them to remain consistent. So, if you take a snapshot of the database at one site, then change some things in the SRM inventory, then restore the database snapshot, you will likely find yourself in a situation where your SRM installation is completely corrupt. Really the only way you could safely do a SQL backup and restore at one site is if the SRM servers are not allowed to communicate with each other in between the backup and the restore. The easiest way to accomplish this is to shut down the SRM server at the other site for the duration.
Recovery plans are stored in the database, though spread out among a large number of different tables. What information are you trying to get at? SRM's database schema was not designed to be ...
See more...
Recovery plans are stored in the database, though spread out among a large number of different tables. What information are you trying to get at? SRM's database schema was not designed to be convenient for third parties to interpret. If you're looking for a specific piece of information, it may be available elsewhere.
The list of necessary connectivity is: Each SRM must be able to talk to its local VC: Prod-SRM <--> Prod-VC DR-SRM <--> DR-VC Each SRM must be able to talk to its remote VC: Prod-SRM <--...
See more...
The list of necessary connectivity is: Each SRM must be able to talk to its local VC: Prod-SRM <--> Prod-VC DR-SRM <--> DR-VC Each SRM must be able to talk to its remote VC: Prod-SRM <--> DR-VC DR-SRM <--> Prod-VC That's it. The two VC servers do not need to be able to connect to each other, nor the two SRM servers to each other. Messages sent from one SRM to another are routed through the VC server at the site that is receiving the message.
This means the two vCenter servers need to be able to talk to each other over port 80 by default. This isn't quite correct; the two vCenter servers don't send any data between them. Instead...
See more...
This means the two vCenter servers need to be able to talk to each other over port 80 by default. This isn't quite correct; the two vCenter servers don't send any data between them. Instead, an SRM server at site A communicates with his partner at site B via the vCenter proxy on site B. Communication in the opposite direction flows through site A's proxy. In other words, each packet between SRM servers flows through only one vCenter proxy - the one at the destination site. So, each SRM server needs to be able to communicate with both vCenter servers, but the vCenter servers don't need to be able to talk to one another, nor the SRM servers to each other.
Looks like an error in the admin guide. Try this path: C:\Program Files\VMware\VMware Site Recovery Manager and this config file: C:\Program Files\VMware\VMware Site Recovery Manager\...
See more...
Looks like an error in the admin guide. Try this path: C:\Program Files\VMware\VMware Site Recovery Manager and this config file: C:\Program Files\VMware\VMware Site Recovery Manager\config\ vmware-dr.xml
\[2006-10-30 10:15:30.695 'BaseLibs' 3248 warning] VmdbCtxGet: Failed to get /vm/#bf2c34477fb4bf32/vmx/rawCfgState/val/all/#_annotation/value/ (The supplied buffer is too small) Does your VM ...
See more...
\[2006-10-30 10:15:30.695 'BaseLibs' 3248 warning] VmdbCtxGet: Failed to get /vm/#bf2c34477fb4bf32/vmx/rawCfgState/val/all/#_annotation/value/ (The supplied buffer is too small) Does your VM have a large annotation? There is a known issue in which VM Importer and Converter can choke on VMs with very large annotations. If this is the case, try paring it down (or temporarily deleting it) and try the import again.
When Virtual PC or Virtual Server suspends an image, it creates a .vsv file with the same base name as the .vmc file in the same directory. If you have one of these files hanging around, it coul...
See more...
When Virtual PC or Virtual Server suspends an image, it creates a .vsv file with the same base name as the .vmc file in the same directory. If you have one of these files hanging around, it could be confusing VM Importer - try deleting it.
Run VM Importer and select the source VM's configuration file as your source. Then, enter the IP address or DNS name of your ESX 3.0 machine on the managed destination page. There is a major ...
See more...
Run VM Importer and select the source VM's configuration file as your source. Then, enter the IP address or DNS name of your ESX 3.0 machine on the managed destination page. There is a major catch to be aware of, though. If the source VM uses IDE disks, you will run into trouble because ESX only supports SCSI. VM Importer will automatically convert IDE disks to SCSI, but the guest operating system may not be equipped to handle them, and will probably not boot up. It should be possible to get the new VM to boot either by mounting its virtual disks in another VM and editing necessary settings, or by setting the guest OS of the source VM to boot from SCSI before importing. edit: To clarify, if the guest OS is Windows, VM Importer will reconfigure the new VM automatically to boot up on its new virtual hardware. Only non-Windows VMs may require reconfiguration of the guest OS by hand. Message was edited by: GRedner
^^ VM Impoter 2 will replace IDE disks with SCSI disks when migrating to ESX, and modify the guest (Windows only) operating system to correctly identify and boot from the new disks. Importing o...
See more...
^^ VM Impoter 2 will replace IDE disks with SCSI disks when migrating to ESX, and modify the guest (Windows only) operating system to correctly identify and boot from the new disks. Importing other guest OSes to ESX will still result in SCSI disks, but the guest OS may have to be modified by hand to accept them. To import from GSX to ESX 2.5, the server must be managed by VirtualCenter 2. To import to ESX 2.5, select the source VM's .vmx file as the source, and enter the VC server's IP address (or DNS name) as the destination, then select the desired ESX 2.5 host from the resulting page. To import from ESX 2.5 to GSX, select the VC server's address as the source, then select the VM you want from the resulting list page. For the destination, choose the directory in which the imported VM should reside.
Hi Dave, The 2GB option will only affect the types of disks that can be created. VM Importer already supports reading from 2GB split disks. The errors you are getting are very strange. We...
See more...
Hi Dave, The 2GB option will only affect the types of disks that can be created. VM Importer already supports reading from 2GB split disks. The errors you are getting are very strange. We do support importing VMs with snapshots, so it is disturbing that your import succeeded after the snapshots were removed. There also should not be any problem reading VMs from a FAT32 partition. Would you post the error logs for some of the failed cases? Alternatively, you could email them to vmi2-betafeedback@vmware.com
Hi Dave, It is possible to change the sparseness of created disks via the "Allocate all disk space now" checkbox on the Virtual Machine Options page. However, the beta version of VM Importer ...
See more...
Hi Dave, It is possible to change the sparseness of created disks via the "Allocate all disk space now" checkbox on the Virtual Machine Options page. However, the beta version of VM Importer provides no way to create 2GB split disks. This ability will likely be added before the next release.
The beta does not check disk space correctly for Ghost images. Does the image you are importing perhaps have a 101GB virtual disk, of which only 13GB is filled? If that were the case, this be...
See more...
The beta does not check disk space correctly for Ghost images. Does the image you are importing perhaps have a 101GB virtual disk, of which only 13GB is filled? If that were the case, this behavior would be expected.