5 Replies Latest reply: Dec 20, 2012 4:08 PM by 979816 RSS

    Cloning  process with VDI 3.4.1 and vCenter 5.0.0

    979816
      Does anyone know the precise cloning process VDI 3.4.1 is using with pools using a vCenter 5.0.0 provider? As far as I can tell, the process is as follows:

      1) Copy (or create linked clone of) template to VM
      2) Power on VM using customization specification
      3) Sysprep runs and reboots the VM
      4) Customization occurs and the VM reboots again
      5) VDI waits for RDP to become available
      6) As soon as RDP becomes available, VDI takes a snapshot, even if RunOnce scripts are not complete
      7) VDI marks the VM as available

      Due to the timing of step 6), when a VM is recycled, it is reverted to a snapshot in an indeterminate state. Shouldn't VDI wait for the VM to shut down before taking a snapshot?
        • 1. Re: Cloning  process with VDI 3.4.1 and vCenter 5.0.0
          979816
          Does anyone from Oracle monitor these forums? Seems no-one else knows the answer to my question...
          • 2. Re: Cloning  process with VDI 3.4.1 and vCenter 5.0.0
            daniel whitener
            I'm not positive on this... I'm only guessing based on what I have seen, but I suggest that maybe step 6 is not correct... I would guess that step 6 has something to do with the VDA tools that are loaded on the machine. I'm wondering if it gets the machine's IP from vcenter, attempts to contact the vda service running on that IP rather then the RDP service.

            Anyway, in my environment, using vsphere 4.1, the snapshot is taken after step 6 -- but only after the machine has shut down. However, please note, I am not using any "RunOnce" scripts in my deployment.

            Regarding your question about when the snapshot SHOULD be taken, what is your pool cloning setting for "Machine State" (Power state for desktops after cloning or recycling)? Mine is currently set to "Power Off" which matches the action I see... the completely deployed machine is powered off and a snapshot is taken.

            I'll forewarn you I think the number of vsphere users for virtualization is a bit weak here unfortunately.

            good luck
            daniel
            • 3. Re: Cloning  process with VDI 3.4.1 and vCenter 5.0.0
              979816
              Thanks, Daniel - your suggestion about the "Machine State" setting was just what we needed. We never suspected that setting, since an identical setup using VirtualBox instead of vmware behaves completely differently. With "Machine State" set to "Running" on a VirtualBox desktop provider, VDI still shuts down the VM after cloning and before taking a snapshot, and restarting the VM. With vmware, VDI doesn't do the shutdown before taking the snapshot unless "Machine State" is set to "Power Off".

              Just as an FYI regarding your comment about the vda-tools, it seems that VDI is not using them post-cloning - the shutdown and snapshot action is definitely triggered by RDP becoming available. I confirmed that directly using Windows Firewall settings.
              • 4. Re: Cloning  process with VDI 3.4.1 and vCenter 5.0.0
                daniel whitener
                One thing I have never quite nailed down is how the VDI servers determine user connection state on a desktop... in other words, what user is logged in, and whether their session is active or disconnected. I always assumed it was the vda-tools, but maybe it's smarter than I give it credit and it can pull that from RDP somehow?
                • 5. Re: Cloning  process with VDI 3.4.1 and vCenter 5.0.0
                  979816
                  From what I can tell, VDI uses RDP availability to determine when a clone is available, but it uses vda-tools to determine when someone logs on. Without vda-tools installed, a VM will be assigned to a user, but remain in "Idle" state even after the user logs on. With vda-tools installed, the VM will be in "Used" state after the user logs on (although it can take up to a minute to happen - must be a polling interval). I remember reading somewhere (recently, while debugging this issue, but I can't remember where I read it) that vda-tools sets guest properties in vmware to achieve this, and then the vda service polls this information.