We have problems with network settings for recovered virtual machines managing with vCloud Director Availability if we use manual ip configuration in vCDA recovery setting wizard on outgoing replicat...
See more...
We have problems with network settings for recovered virtual machines managing with vCloud Director Availability if we use manual ip configuration in vCDA recovery setting wizard on outgoing replication by the book as we speak. No matter what we chose test or migrate/failover if we setup ip manually, connect all network, good NIC networ, and enable customization virtual machine doesn't got ip address right one. On vCD side for network view for vm we can see the new address and good network, but on client side there is no changes. On recovered virtual machine vmtools are up, but version is lower than on hosts for vCD. Also, I got it if I chose customization and select put some name of vm recovered vm has name+addon and I think that customization doesnt work. Does someone know what is problem with customization for vCDA? thx
There is no native VDI integration in VCD. In theory, you could still onboard any VDI management solutions in VDC design as per the requirement, and do the integration.
Hi, Anyone managed to install OSE plugin on Rocky linux and Integrate it to vcd 10.0.5.? I keep moving from one error to the next, the install documentation looks straight forward not sure what am ...
See more...
Hi, Anyone managed to install OSE plugin on Rocky linux and Integrate it to vcd 10.0.5.? I keep moving from one error to the next, the install documentation looks straight forward not sure what am missing Current error Error: Fail to install OSE UI plugin as Decode error: unexpected end of JSON input Ref: https://docs.vmware.com/en/VMware-Cloud-Director-Object-Storage-Extension/2.2/Installing-and-Configuring.pdf
It would nice to receive answer to this non-answered question. From my current research's seams Horizon doesn't have any integration with Cloud Director. Also, it seams advised to deploy dedicated...
See more...
It would nice to receive answer to this non-answered question. From my current research's seams Horizon doesn't have any integration with Cloud Director. Also, it seams advised to deploy dedicated vCenter, ESXi just for Horizon Services. This is obviously huge waste of resources for current Cloud Providers based on VMware. There is also an old blog post from 2013. about this https://myvirtualcloud.net/how-to-horizon-view-and-vcloud-director-multi-tenant-daas/ but since this is from ten years ago stating there is no integration between Cloud Director and Horizon. However, VMware might did some progress in this matter in last 10 years. Let's hope that someone can shed more light on this matter.
The problem was not with the kernel, but with one of these software (removed with yum): desktop-file-utils-0.23-2.el7.x86_64 emacs-filesystem-1:24.3-23.el7_9.1.noarch libsecret-0.18.6-1.el7.x86_6...
See more...
The problem was not with the kernel, but with one of these software (removed with yum): desktop-file-utils-0.23-2.el7.x86_64 emacs-filesystem-1:24.3-23.el7_9.1.noarch libsecret-0.18.6-1.el7.x86_64 libxkbfile-1.0.9-3.el7.x86_64 xdg-utils-1.1.0-0.17.20120809git.el7.noarch
This does not provide shadows per catalog item but will dump out the all shadows #$DSName = "datastore_name" $ShadowVMs = search-cloud -QueryType AdminShadowVM -filter "DatastoreName==$DSName" |...
See more...
This does not provide shadows per catalog item but will dump out the all shadows #$DSName = "datastore_name" $ShadowVMs = search-cloud -QueryType AdminShadowVM -filter "DatastoreName==$DSName" | Get-CIView #| select -first 1 $Count = $ShadowVMs | measure | select-object -ExpandProperty Count Write-Host "Moving $Count ShadowVMs in $DSName" $loopCount = 0 Foreach ($ShadowVM in $ShadowVMs) { $loopCount = $LoopCount + 1 $Percent = "{0:N0}" -f (($loopcount / $Count) * 100) Write-Progress -Activity "Deleting $Count ShadowVMs" -Id 1 -Status "$Percent %" -PercentComplete $Percent $ShadowVMName = $ShadowVM.Name $DelTask = $ShadowVM.Delete_Task() Do { $Task = Get-Task -id $DelTask.Id $i = $Task.PercentComplete $state = $Task.State Write-Progress -Activity "Deleting $ShadowVMName with task state $State" -Status "$i %" -PercentComplete $i Sleep -seconds 5 } While (($Task).State -eq "Running") }
I'm digging into the same and was able to find: Shared Named disks cannot be created on NFS as we discussed, The datastore that is linked needs to have at least one non-NFS datastore: Any disk ...
See more...
I'm digging into the same and was able to find: Shared Named disks cannot be created on NFS as we discussed, The datastore that is linked needs to have at least one non-NFS datastore: Any disk to be shared must be: Thick provisioned, eager zeroed (meaning that they cannot reside on an NFS datastore) Disk mode: “Persistent” I'm looking for the official documentation and will share that once I find it.
Hi, you should check the vmkernel logs off the ESXi Sever your Cent OS is running on. As writes seems to fail you should find messages similar to 2011-04-04T21:07:30.257Z cpu2:2050)ScsiDeviceIO...
See more...
Hi, you should check the vmkernel logs off the ESXi Sever your Cent OS is running on. As writes seems to fail you should find messages similar to 2011-04-04T21:07:30.257Z cpu2:2050)ScsiDeviceIO: 2315: Cmd(0x4124003edb00) 0x12, CmdSN 0x51 to dev "naa.600508e000000000c9f6baa7c19f6900" failed H:0x0 D:0x2 P:0x0 Valid sense data: 0x5 0x24 0x0. Mar 9 23:53:24 esx405 vmkernel: 2:14:39:54.069 cpu3:4300)ScsiDeviceIO: 1688: Command 0x28 to device "naa.60000970000292600219533031453245" failed H:0x1 D:0x0 P:0x3 Possible sense data: 0x0 0x0 0x0. Additionally you should check the vmware.log file of that special VM, you'll find it in the same folder where the .vmx file is located.
Hello! Within the UI, there should be metadata (depending on the version you are using) that gives the the name, ID and type that the vApp was deployed from. Those values should be named: v...
See more...
Hello! Within the UI, there should be metadata (depending on the version you are using) that gives the the name, ID and type that the vApp was deployed from. Those values should be named: vapp.origin.id vapp.origin.name vapp.origin.type
Hi, For the past few days my machine every 13-14 minutes crashes and in /var/log/messages I find: Sep 14 15:26:35 MY-VM kernel: mptscsih: ioc0: attempting task abort! (sc=ffff9af030d6b2c0) Sep 14 ...
See more...
Hi, For the past few days my machine every 13-14 minutes crashes and in /var/log/messages I find: Sep 14 15:26:35 MY-VM kernel: mptscsih: ioc0: attempting task abort! (sc=ffff9af030d6b2c0) Sep 14 15:26:35 MY-VM kernel: sd 0:0:0:0: [sda] CDB: Write(10) 2a 00 00 0f b0 48 00 00 08 00 Sep 14 15:26:35 MY-VM kernel: mptscsih: ioc0: task abort: SUCCESS (rv=2002) (sc=ffff9af030d6b2c0) Sep 14 15:26:35 MY-VM kernel: mptscsih: ioc0: attempting task abort! (sc=ffff9af030d6aa00) Sep 14 15:26:35 MY-VM kernel: sd 0:0:0:0: [sda] CDB: Write(10) 2a 00 00 0f b0 80 00 00 08 00 Sep 14 15:26:35 MY-VM kernel: mptscsih: ioc0: task abort: SUCCESS (rv=2002) (sc=ffff9af030d6aa00) Sep 14 15:26:35 MY-VM kernel: mptscsih: ioc0: attempting task abort! (sc=ffff9af030d68fc0) Sep 14 15:26:35 MY-VM kernel: sd 0:0:0:0: [sda] CDB: Write(10) 2a 00 00 0f ce 38 00 00 08 00 Sep 14 15:26:35 MY-VM kernel: mptscsih: ioc0: task abort: SUCCESS (rv=2002) (sc=ffff9af030d68fc0) I can't figure out what it is due to, any ideas?
@Sandesh90031 It is more dependent on what type of infrastructure you have. vCD has no limit on firewall rules specific to OnPrem side. It is mostly dependent on NSX-V or NSX-T that vCD is integrate...
See more...
@Sandesh90031 It is more dependent on what type of infrastructure you have. vCD has no limit on firewall rules specific to OnPrem side. It is mostly dependent on NSX-V or NSX-T that vCD is integrated with. https://configmax.esp.vmware.com/guest?vmwareproduct=VMware%20NSX&release=NSX-T%20Data%20Center%203.2.3&categories=19-47,19-34,19-36,19-120,19-35,19-64 NSX-T 3.x provides 100000 rules as maximums. If vCD is integrated with AWS, Then 50000 is the limit. https://docs.vmware.com/en/VMware-Cloud-Director-service/services/rn/VMware-Cloud-Director-Service-Configuration-Maximums.html Hope this answers your question.
edit the file /opt/vmware/appliance/bin/appliance-sync.sh and find The default value for timeout (/usr/bin/timeout) is 10s, increase it to 30s save the file and restart the procedure
I'm configuring VMware Cloud Director Availability with separate tunnel, management, and replicator appliances. At https://docs.vmware.com/en/VMware-vCloud-Availability/3.0/com.vmware.vcav.cloud.inst...
See more...
I'm configuring VMware Cloud Director Availability with separate tunnel, management, and replicator appliances. At https://docs.vmware.com/en/VMware-vCloud-Availability/3.0/com.vmware.vcav.cloud.install.config.upgrade.doc/GUID-7AD44099-F473-408E-ACA5-B18D9757C79D.html, the only DNAT suggested is the port 443 to port 8048 to the tunnel appliance. I have this but when I do only that, the Cloud Director Availability plugin in Cloud Director doesn't work because that appears to need to go to port 443 on the Management appliance where the tenant portal is. I've tested setting a DNAT 8048 straight through to the tunnel appliance and setting port 443 straight through to the Management appliance and that works. Replication then uses 8048 and tenant management uses port 443. However, I'm not certain this is correct since the documentation clearly shows port 443 goes to 8048 on the tunnel appliance with no other DNAT rule listed. Could someone clarify how the configuration should be for the DNAT ports? Eric
