daphnissov's Accepted Solutions

As of right now, those cluster sizes cannot be modified in a supported way because the CRDs which define them, on the supervisor cluster, cannot be altered. If you need more resources once a cluster is deployed, you would create horizontal scale rather than vertical scale.

Your migration questions as fairly straightforward and quite common. Convert your vDS to vSS on all hosts, disconnect and remove them from the source vCenter, and add them to the destination vCenter. Reverse the process and re-deploy a vDS, then join hosts. Unless you're using solutions like NSX, vSAN, or some others, this "swing" style migration should not impact VMs. Do keep in mind that if you're using backup, monitoring, replication, or other external tools that integrate with vCenter that, once you do this, typically it will see those same VMs on the other vCenter as "new" and will treat them as such. _____________________________________________________________ "Did you find this helpful? Let us know by completing this survey (takes 1 minute!)"

The solution here is to ensure your DNS service, which is a core, critical piece of infrastructure, is always available. This isn't something that vSphere aims to solve but is instead a requirement upon which it depends. You should take care to have multiple DNS servers with at least one not running on the clusters managed by this vCenter.

That's a futures question which you probably aren't going to get answered publicly here. Your best shot is going to be to speak with your partner manager (if a partner), your TAM, or your account manager and ask for an NDA roadmap briefing.

To my knowledge, this is not possible. Even an intra-vCenter svMotion of individual disks I don't think is possible. Happy to be schooled here, but normally the procedure would be to shutdown the VM and manually move those disks, then reconfigure the VM.

You wouldn't use that controller to host a disk on which you'd then install ESXi. That controller should be dedicated to vSAN, and using pass-through (JBOD) is the recommended method. ESXi would need to be installed on a SATADOM drive, internal flash, or something else.

Firstly, you posted this in the wrong sub-forum. This one is for vRealize Automation. You should move this to vRealize Operations. Secondly, you have a really old version of vROps that is in dire need of upgrading. Third, how are you monitoring this DC? It's possible it rebooted so quickly as to fall under vROps' default 5-minute collection window.

That demo appliance is for TKG multicloud, which is different from vSphere 7 with K8s. If you already have the latter, you're all set. You will still have to deploy TKG clusters to use NodePort, but this shouldn't be your first choice. Service of type LoadBalancer is usually preferred with or without an Ingress service.

Perform an upgrade/migration from vCenter 6.5 for Windows to vCSA 6.7. The PSC should get upgraded first. Once upgrade is complete, do a converge to an embedded PSC. ___________________________________________________________________________ "Did you find this helpful? Let us know by completing this survey (takes 1 minute!)"

I've already answered this question, so let me say another way in a simpler manner. The so-called "vSphere Pods" feature is a capability of vSphere with Kubernetes add-on. There are other capabilities included. At this time, you can only purchase this add-on as part of VCF. So effectively, ​you cannot use this without VCF​.

2020-07-01T17:47:32Z esxupdate: 3079151: imageprofile: INFO: Adding VIB VMware_bootbank_spherelet_1.0.2-16215255 to ImageProfile (Updated) DellEMC-ESXi-6.7U1-10764712-A04 The solution is called "vSphere 7 with Kubernetes" but you have ESXi 6.7 U1. You cannot run this solution with ESXi 6.7. Everything has to be at 7.0. Cloud you please confirm that this issue is related to SSO domain. No, I cannot, however this is a point of best practice. Don't change defaults if you don't know what they do.

Lots of different questions here so let's go through them one by one. Before that, however, the general response is, yes, it's safe to snapshot VMs when they're running and this is done millions of times a day for even the most critical workloads. The interesting parts arise when you need to then perform an action with that snapshot. Can something happen to these connections while the snapshot is being taken ? Can data corruption occur somehow ? Generally speaking, no, especially to the second question. Connections should also be maintained because the snapshot process completes extremely quickly on most VMs. The instance in which connections ​may be dropped is if you have a large number of virtual disks, you have poorly-performing backend storage, and you quiesce a system with much transactional I/O. Does the type of server matter ? Not really. They both snapshot similarly, however there are different mechanism used to quiesce the system based on the OS type. More below. Software: Database (postgresql, mysql, Oracle), Application with Frontend and Backend, applications that read/write from/to files, applications that read/write from/to databases, ... This is one of the rubs, not with taking the snapshot or even deleting it, but reverting to it. When taking a snapshot of a powered-on system, by default the "quiesce" option is not enabled. With this option disabled, the snapshotting of the disks takes place without any coordination inside the guest. When reverted, the guest comes back up exactly like there was a power outage or a cut. In most cases, this is fine, even with some databases that write to a T-log first like Postgres. Other databases like MySQL and Oracle are less tolerant of this and require quiescence when the snapshot is taken. This process communicates with a piece of software inside the guest and coordinates with the applications who respond to these quiesce requests to flush any in-memory data buffers to backend disk. Once this flush is done, the databases are said to be in a "consistent" state at which point the snapshot is taken. This ensures if the snapshot must be reverted the system returns to a known good state. Of course, that's not to say the only way the system will return to operation is with the quiesce option enabled, but it is the safest way especially for systems that have a transactional database installed within them. This safety is especially important when VM backups occur as they leverage snapshots to prepare the system. Some vendors have even gone so far as to write their own quiescence drivers and not rely on those that come from VMware. If issues arise during the changes that I am making, will I be able to safely restore the server to the snapshot without any issues, regardless of the type of server I am running ? Answered above in regard to snapshot reversion. The other operation is a delete in which case the previous process is unrelated. A delete involves incorporating back into the base disk the changed blocks after the snapshot was taken and therefore accepting those changes that occurred after point of snapshot. Hope this answers your questions.

Some commentary on this plan. Wipe it out and install ESXi 6.7 or 7 and install a new vCenter on Windows on that host. Please don't even think of doing this. vCenter for Windows is dead and has been for a while. In fact, it's not even an option in vSphere 7. Using the vCenter Server Appliance (vCSA) should be the path you take regardless of your target version. I will removed all the VMs from inventory on the 5.1 host and add all the VMs to inventory on the new host/vCenter.  Then I will install from scratch 6.7 or 7 on that other host and add it to the new Cluster.  Then I will update all VM Hardware / Tools etc, setup HA, DRS again etc and apply the licensing that I am inheriting from the other department. Assuming you have shared storage here, correct? You will want to ensure that shared storage can be seen and mounted by both versions simultaneously. You'll also want to ensure those VMs are of high enough hardware version. Bringing them all up to v7 or v8 is probably the best. And before doing any of this, make very sure you have good, full backups of all VMs just in case. Did you find this helpful? Let us know by completing this survey (takes 1 minute!)

ESXi is not Windows nor is it Linux (or even based upon Linux), so therefore just because you were able to install one of those OSs with your on-board RAID controller doesn't mean it'll work with ESXi. What is the model of your motherboard/server? It sounds like it's a software (i.e., fake) RAID controller, and ESXi does not support those at all.