PredatorVI's Posts

PredatorVI · ‎02-12-2018

True, but I'm new to VRO and there is a level of confidence I'm lacking in my setup if I can't even check for updates. I went ahead and attempted to configure it via https://10.131.24.26:8283/...

True, but I'm new to VRO and there is a level of confidence I'm lacking in my setup if I can't even check for updates. I went ahead and attempted to configure it via https://10.131.24.26:8283/vco-controlcenter/ it seemed to initially work. I connected it to my vcenter server using administrator@vsphere.local and set my Administrators group to "Administrators" and when I saved the configuration all I get now when hitting the control center URL at https://10.131.24.26:8283/vco-controlcenter/ is yet another 404.

PredatorVI · ‎02-12-2018

I'll assume the URL is correct since that's what was configured out of the box and (im)patiently wait to see if resolves itself. I tried to validate the URL, but can't find any documentation to ...

I'll assume the URL is correct since that's what was configured out of the box and (im)patiently wait to see if resolves itself. I tried to validate the URL, but can't find any documentation to help.

PredatorVI · ‎02-12-2018

I can't find any resolution to this. It's a fairly new installation that I haven't fully configured yet. Anyone know what the cause of this might be? Last Check: Failed to check for update...

I can't find any resolution to this. It's a fairly new installation that I haven't fully configured yet. Anyone know what the cause of this might be? Last Check: Failed to check for updates(Error downloading manifest. Please contact your vendor. The requested URL returned error: 404 Not Found URL: https://vapp-updates.vmware.com/vai-catalog/valm/vmw/00642c69-abe2-4b0c-a9e3-77a6e54bffd9/7.3.0.141.latest/manifest/manifest-latest.xml) on Monday, 2018 February 12 08:51:26 UTC-7

PredatorVI · ‎02-06-2018

Thanks! I thought that when communication happened on one interface, the switch would route responses back through the same. Maybe I'm confusing the non-Etherchannel configuration. Regardless,...

Thanks! I thought that when communication happened on one interface, the switch would route responses back through the same. Maybe I'm confusing the non-Etherchannel configuration. Regardless, this makes perfect sense.

PredatorVI · ‎01-30-2018

I'm hoping for some enlightenment since my current understanding is lacking and I can't find the answer elsewhere. My ESXi Servers have 8 x 1GbE ports that we use with (currently) two VLAN ids...

I'm hoping for some enlightenment since my current understanding is lacking and I can't find the answer elsewhere. My ESXi Servers have 8 x 1GbE ports that we use with (currently) two VLAN ids (110, 124) connected to a Cisco 3750 switch stack. The configuration has two Etherchannel port groups configured on the switch stack. Each port group is set to use 802.1Q trunking and Mode set to "On (No LACP)" on the Cisco switches with 4 ports assigned to each. These directly map to individual vSwitches as shown below. The vSwitch load balancing algorithm is "Route based on IP Hash" and all seems to work fine in this scenario. However we ran out of Etherchannel port group IDs (48 Max) on the switch stack. I thought that I could simply combine the Etherchannels and connect all 8 physical ports into ONE 8-port Etherchannel and keep the existing dual vSwitch configuration to maintain functionality. However that didn't appear to work. If 4 ports are assigned to vSwitch0 and 4 to vSwitch1 as shown above, with a single, 8-port Etherchannel configured at the switch, communication stopped working. We were able to get it to work if we combined the two vSwitches into one such as: My question is why didn't it work with two vSwitches? There is probably a simple explanation but I'm lacking some understanding. Thanks!

PredatorVI · ‎01-08-2010

I have VM's that are all provisioned as "thin", but as soon as I take a snapshot, the VM "Edit Settings" shows that it is now "thick". We are running ESX 4.0. If I then remove the snapshot(s), t...

I have VM's that are all provisioned as "thin", but as soon as I take a snapshot, the VM "Edit Settings" shows that it is now "thick". We are running ESX 4.0. If I then remove the snapshot(s), the disk reverts back to "thin" It doesn't appear that the disk really becomes thick in the source VM. Disk usage remains as expected. The kicker comes when you try to clone a VM with the snapshot. If I don't change the default Disk Format from "Same format as source" to "Thin provisioned format", the clone becomes thick. Cloning a single VM is not the problem since I can simply select "thin" when prompted. The real problem comes when I clone an entire vApp. We are using vApps to group and contain complete testing environments. It is very convenient to clone the entire vApp. However, cloning a vApp does not prompt and ask how to treat the disk format for the clones and seems to take the default "Same format as source" which it now thinks is "thick"! Is there a way to change the default behavior for cloning to "thin"? This would solve my problem, even though snapshots are f.u.b.a.r.-ing the disk format. Otherwise I think this is a bug.

PredatorVI · ‎01-08-2010

Ah...didn't notice that. I read through the thread and there seemed to be an outstanding request (or two) to see if anyone else had seen this behavior. Starting a new post now...

PredatorVI · ‎01-07-2010

I am seeing the behavior described initially in this thread where I have VM's that are all provisioned as "thin", but as soon as I take a snapshot, the properties say it is "thick". We are runni...

I am seeing the behavior described initially in this thread where I have VM's that are all provisioned as "thin", but as soon as I take a snapshot, the properties say it is "thick". We are running ESX 4.0. It doesn't appear that the disk really becomes thick, unless you try to clone and tell it to keep the disk format the same as the source. At this point, the clone becomes thick. Cloning a single VM is not the problem as it is simple to just select "thin" when prompted. The real issue comes when we clone an entire vApp. We are using vApps to group and contain complete testing environments. It is very convenient to clone the entire vApp. However, cloning a vApp does not prompt and ask how to treat the disk formats for the clones within the vApp so it defaults to keeping it the same as the source which it now thinks is "thick"! Is there a way to change the default behavior for cloning to "thin"? This would solve my problem, even though snapshots are f.u.b.a.r.-ing the disk format.

PredatorVI · ‎12-18-2009

I'm running a small test lab for the product I work on and we have been using vApps to manage various testing environments. We are running ESX4 and vCenter Server. It seems to be a no-brainer t...

I'm running a small test lab for the product I work on and we have been using vApps to manage various testing environments. We are running ESX4 and vCenter Server. It seems to be a no-brainer that a person would want to do a simultaneous snapshot of the entire vApp's state from the vSphere Client. Is this feature even a glimmer in the eye of the VMWare team? If so, what would likely be the timeframe? Thanks!

All

PredatorVI's Posts

Re: VRealize Orchestrator Appliance 7.3.0 fails to check for updates (404 Not Found)

Re: VRealize Orchestrator Appliance 7.3.0 fails to check for updates (404 Not Found)

VRealize Orchestrator Appliance 7.3.0 fails to check for updates (404 Not Found)

Re: Splitting Etherchannel ports between multiple vSwitches?

Splitting Etherchannel ports between multiple vSwitches?

ESX4 VM with thin provisioned disk shows thick when a snapshot is taken..

Re: Snapshots and Thin Disks

Re: Snapshots and Thin Disks

Support for vApp snapshots...am I missing it?