vCenter services after upgrade

S

Sp33dFr33k

2[H]4U
Joined
Apr 20, 2002
Messages
2,481
Recently upgraded from vCenter 5.1 to 5.5

During the upgrade I had to use a domain account (mine) to complete the upgrade (none of the options to use another account were enabled).

Now I have two services running under my user account. Previously they ran under Local System like the other services.

Can I switch them back to Local System or should I create a service account for these two services?
 
I have done it both ways. Using a service account and using Local System. I believe the correct way is using a service account, but I am not sure what purpose it serves since it works perfectly fine as Local System.
 
What is in the manual for 5.5 is that it's supposed more secure to use a domain account and not the Local System. I guess I'll just try to switch it to local system and confirm it's working and leave it like that.
 
I have VirtualCenter Server, VirtualCenter Management Webservices, vSphere Update Manager Service and vSphere Profile-Driven Storage Service all running under a service account in 5.5. Everything else is using the local system account.
 
FWIW, all of my VMware related services are running as Local System, except VMwareVCMSDS which is running as Network Service

This is with 5.5U3
 
The primary reason for running vpxd with a service account is using windows based authentication to SQL server; in that case the service would run under the account that has permissions to the database. If you're using non-windows (SQL auth) or Oracle, it doesn't make a difference and local system is fine. Many security guides, like the the DOD / DISA STIG require that you run it under a service account vs local system.

As long as it has admin rights with the user account you create, it should be fine. There is (I think) a requirement that you use the local security policy editor to change it so that the account you use has the ability to "act as part of the operating system". I'm sure you could find the documentation.

Either way, it sounds like you got what you wanted.
 
defuseme2k said:
The primary reason for running vpxd with a service account is using windows based authentication to SQL server; in that case the service would run under the account that has permissions to the database. If you're using non-windows (SQL auth) or Oracle, it doesn't make a difference and local system is fine. Many security guides, like the the DOD / DISA STIG require that you run it under a service account vs local system.

As long as it has admin rights with the user account you create, it should be fine. There is (I think) a requirement that you use the local security policy editor to change it so that the account you use has the ability to "act as part of the operating system". I'm sure you could find the documentation.

Either way, it sounds like you got what you wanted.
Click to expand...

This is the only reason. If you use local system, your SQL instance is on the same server, or you configured the permission for the computer account--neither of which are favorable.
 
Run it as an appliance and have no need for Windows Accounts to worry about and make it faster and a lesser foot print? :)
 
MrGuvernment said:
Run it as an appliance and have no need for Windows Accounts to worry about and make it faster and a lesser foot print? :)
Click to expand...

Using the virtual appliance doesn't guarantee (or infer) better performance/speed, however with 6.0 it is very close.

The biggest benefit of using the virtual appliance is that it's a single VM (not considering an external PSC) that is always consistent and easy to update. There is also nowhere else for VMware to point finger on a support case, as the solution is fully-managed/designed by them.

Just make sure you have backups of the database. I've been doing it to an NFS share so that a quick restore would be easy if the whole VM was lost or corrupted.
 
The other issue with the virtual appliance is there's no way to easily migrate to it. It's not like you can import your SQL db in or even better just attach to the db, you either need to do a swing migration to a new instance or hope the fling appliance can handle your config.
 
Migrate it you would simply move the VM to new host and your done?

No SQL to worry about
No DB dumps to worry about
No Windows stuff to worry about..

VM and move, your done.
 
MrGuvernment said:
Migrate it you would simply move the VM to new host and your done?

No SQL to worry about
No DB dumps to worry about
No Windows stuff to worry about..

VM and move, your done.
Click to expand...

So I have to setup a new host, install the appliance, setup a second host for some redundancy, install new Cisco VSMs and VSGs, install Cisco VEMs and migrate the network to the distributed switches and then I'm finally ready to start the swing migration for the VMs in that cluster. Then I get to reconfigure the the hosts for the other 5 clusters. So sure, VM and move...
 
ND40oz said:
The other issue with the virtual appliance is there's no way to easily migrate to it. It's not like you can import your SQL db in or even better just attach to the db, you either need to do a swing migration to a new instance or hope the fling appliance can handle your config.
Click to expand...

You actually can do this. Backup the database and restore on the target.

http://kb.vmware.com/selfservice/se...ype=kc&docTypeID=DT_KB_1_1&externalId=2091961

The Python backup and restore scripts are even included in the KB. I'm not sure of the implications for certificate management on a foreign server, but even if you had to regen all of them it wouldn't be so bad.
 
REDYOUCH said:
You actually can do this. Backup the database and restore on the target.

http://kb.vmware.com/selfservice/se...ype=kc&docTypeID=DT_KB_1_1&externalId=2091961

The Python backup and restore scripts are even included in the KB. I'm not sure of the implications for certificate management on a foreign server, but even if you had to regen all of them it wouldn't be so bad.
Click to expand...

Looks like that's only for the embedded postgres db, not an external SQL db. The only thing I've found for an external SQL db is the Fling appliance which seems to be very configuration specific. I'm a little worried how it'll handle the cisco stuff as well as the horizon view environment. So right now the plan is to rebuild everything with the appliance and migrate to it, which is going to be some work.
 
ND40oz said:
Looks like that's only for the embedded postgres db, not an external SQL db. The only thing I've found for an external SQL db is the Fling appliance which seems to be very configuration specific. I'm a little worried how it'll handle the cisco stuff as well as the horizon view environment. So right now the plan is to rebuild everything with the appliance and migrate to it, which is going to be some work.
Click to expand...

I've done several migrations from a Windows based vCenter to the Appliance with zero downtime. I don't use Horizon View, so I am not sure about that part of the integration.
 
ND40oz said:
Looks like that's only for the embedded postgres db, not an external SQL db. The only thing I've found for an external SQL db is the Fling appliance which seems to be very configuration specific. I'm a little worried how it'll handle the cisco stuff as well as the horizon view environment. So right now the plan is to rebuild everything with the appliance and migrate to it, which is going to be some work.
Click to expand...

The only external database supported by the VCSA is Oracle. MSSQL/MySQL are not supported on the appliance. For Oracle, the backup process should be exactly the same, just with RMAN.

I am not familiar with your Cisco setup, but Horizon View migration wouldn't be too difficult. You may be able to get by just adding the additional vCenter Server and updating your pool configurations (with zero downtime). Worse case scenario, you can manually re-add the VDI instances to a manual pool configured with the new vCenter.
 
KapsZ28 said:
I've done several migrations from a Windows based vCenter to the Appliance with zero downtime. I don't use Horizon View, so I am not sure about that part of the integration.
Click to expand...

While this is possible with the unsupported VMware fling, sometimes it's easier to accept the vCenter downtime and perform a manual migration. Much cleaner and unless your environment is gigantic, it can be done over time in conjunction with other cleanup/maintenance efforts. No matter what type of migration you are doing, there should be no VM downtime as the ESX hosts will be up and running through the entirety.
 
REDYOUCH said:
The only external database supported by the VCSA is Oracle. MSSQL/MySQL are not supported on the appliance. For Oracle, the backup process should be exactly the same, just with RMAN.
Click to expand...

Yeah, it looks like I'll either need to go with the embedded or switch over to Oracle. IIRC they didn't support Oracle with the appliance at the beginning either, be nice if they added SQL support. Been using the same DB since 2.5, apparently I just chose wrong back then when I went with SQL.

REDYOUCH said:
I am not familiar with your Cisco setup, but Horizon View migration wouldn't be too difficult. You may be able to get by just adding the additional vCenter Server and updating your pool configurations (with zero downtime). Worse case scenario, you can manually re-add the VDI instances to a manual pool configured with the new vCenter.
Click to expand...

This is why I think the swing migration is best. I "should" be able to do the entire thing with no downtime, it just involves rebuilding everything and migrating to it. The distributed switches are the main issue as you can't migrate the hosts, you need to migrate the networking off the distributed switch, uninstall the distributed switches, move the host and then reinstall the distributed switches and then migrate the networking back to the new distributed switch.

Anyway, the my point was, moving to the appliance isn't a trivial thing for some environments.
 
I 'm avoiding 5.5 like a plague.

Straight to 6.x for us. Making a clean break and using the VMCA as well. The only issue I'm encountering is the built in gray to green alarm bug. But that is not a show stopper.
 
We've had no issues with 5.5u3 vCenter so far. This year our hosts are going to be upgraded to 5.5 u3 as well.
 
Other than 5.5 gave us little/nothing over 5.1 U2 and the webclient feels like you poured molasses into it....yea Its fine.

I am aware they patched 5.5 into not being so horrid. But I usually judge a product by how their community responds to the beta. 5.5 is/was one of the worst received vsphere versions in my memory. During beta...the inital community response was...wow this DOESN'T suck. Which was a significant improvement over the reception of 5.5.

If you don't believe me. Go install the VCSA 6 into your cluster. You can have it installed and running in an hour. Login to the web-client and take a look around. No hosts needed. Delete it when you're done taking a look.

Granted the VCSA does not have the update manager component. That requires a separate windows based install and takes significantly longer to install, but after integrating the two the gui shows up in the VCSA.


Anyone who's considering a 5.5 deployment should take a look.
 
Last edited:
Mackintire said:
Other than 5.5 gave us little/nothing over 5.1 U2 and the webclient feel like you poured molasses into it....yea Its fine.

I am aware they patched 5.5 into not being so horrid. But I usually judge a product by how their community responds to the beta. 5.5 is/was one of the worst received vsphere versions in my memory. During beta...the inital community response was...wow this DOESN'T suck. Which was a significant improvement over the reception of 5.5.

If you don't believe me. Go install the VMCA 6 into your cluster. You can have it installed and running in an hour. Login to the web-client and take a look around. No hosts needed. Delete it when you're done taking a look.

Granted the VMCA does not have the update manager component. That requires a separate windows based install and takes significantly longer to install, but after integrating the two the gui shows up in the VMCA.


Anyone who's considering a 5.5 deployment should take a look.
Click to expand...

Why do you keep saying VMCA? Being that you replied to my post about SSL certificates I just assumed you were referring to the VMware Certificate Authority which is what VMCA stands for. Otherwise if you are referring to the vCenter Server Appliance, it is still VCSA. Sorry, just a pet peeve. :p
 
ACK.... was running on no sleep yesterday.


You are correct VCSA is what I've been mumbling about.
 
You must log in or register to reply here.
Back
Top