KFM's Posts

You should convert the dynamic disks to basic disk. This can only be done if the mirror is broken. Converter can not handle dynamic disks, see many forums discussions. good luck Actually it can handle dynamic disks, but for best results I recommend to do a cold clone rather than a hot clone. See my post here http://www.vmware.com/community/thread.jspa?messageID=618663&#618663

OK, have just done some testing of my own and these are my findings. Whilst Converter 3.0 will hot clone a machine with dynamic disks and software RAID1, RAID1, RAID5 the resultant VM will not boot and gives a "no OS found". I then booted the VM with a modified bartPE CD with Vmware SCSI drivers and noted that the disk partitioning had changed. Converter had changed the disk layout to be one large EXTENDED partition with my C and D drives as logical partitions inside the extended partition. AFAIK, you can't boot Windows off a partition that exists inside an extended partition. (Correct me if I'm wrong but I couldn't get it working no matter what). So what's the fix? As mentioned earlier, first break the software mirror using disk manangement, then during the hot clone, just select ONE disk that you want to P2V to the resultant VM. But what if it's not a software mirror and instead is a RAID0, RAID5 or spanned volume? Clearly, breaking the set is unacceptable since you'll lose all the data on the volumes. I found that if I perform a cold clone, and on the "Source Data" option page, select "Import all disks and maintain size" (this option is greyed out when doing a hot clone) then the P2V process works perfectly with a bootable OS On a side note, I also found that even though I was P2Ving a Windows Server 2003 machine, the resultant vHardware was using a Bus Logic SCSI controller (even though it should be LSI logic, and hence giving me a 0x7b BSOD stop error) and it also had virtual serial ports, parallel ports and USB controller. Surely Converter should be smart enough to NOT include all these peripheral ports, especially since it's a VMware product!? </rant>

Seems like this problem (which I'm also experiencing) may be fixed with VC 2.0.1 Patch 2. http://www.vmware.com/support/vi3/doc/vc-201-200702-patch.html If it's not fixed then at least it will provide for an easy way to restart the VC server service if/when it stops. "VirtualCenter Service Can Be Configured to Re-start Automatically. In previous releases, when the VirtualCenter database server went off-line for any reason, the VirtualCenter service shut down with a normal termination signal, and because the termination signal was deemed normal, the Windows Service Control Manager never attempted to restart the VirtualCenter service. With this release, the service recovery options can be configured to restart the VirtualCenter Server service automatically when this type of event occurs. By default, the service is configured to restart once, but you can modify the VMware VirtualCenter Server service control panel Recovery settings to restart after second failure and subsequent failures if you like." I'm going to roll this update out and see how it goes. Message was edited by: KFM

The VM will get no more then 512 MB, but this is misleading because it can share identical pages of memory from the other OS. Not misleading at all. What transparent page sharing means is that ESX server has some trickery that allows it to see which pages amongst all the guest OSes are identical. It then only has to create one page which is shared for all guest OSes. It's a way ESX server can save memory by sharing common pages between guest OSes. Transparent page sharing is exactly that - transparent to the guest OS. It doesn't see any less, or more memory just because page sharing is used. (For the record, once a guest OS modifies that particular page, ESX server immediately copies it out and allocates it it's own copy, whilst the other guest OSes which were sharing it, still share the original page) If increase the number of shares on this VM, it will have a higher priority if multiple machines are competing for memory resources. Spot on - you're correct. I am still a little confused between the difference between the memory on the hardware tab and the reservations on the "resources tab" . The amount of RAM you allocate a VM via the hardware tab is the amount reported to the guest OS. This is basically the limit you're specifying. A reservation means that ESX server will reserve that amount for the guest OS if it requires it, eg when there is contention for resources, then the guest OS is guaranteed the amount you reserved for it. What happens if the "hardware" tab has 512 MB and the "Resources" tab has 2GB" This isn't possible. If you set a VM to have 512MB RAM via the hardware tab, then the maximum reservation ESX will allow you to allocate to it will be 512MB. Try it and you'll see what I mean. Hope this clears up some of your confusion?