Private VLANs in vSphere

PVLANs is one of those features that everyone should have in their mental “toolbox”.  We were looking for a way to fence off portions of a network with minimal effort, but they didn’t really require a whole separate subnet. For example, maybe to enhance security, or for pre-production VMs.  (Obviously, this is assuming properly configured switches)  For those that are unfamiliar with PVLANs, check out VMware’s KB on the subject. Essentially, it allows you to further segment a VLAN using different groups (promiscuous, isolated, community)

The promiscuous group can talk to all other groups.  The community group can talk among itself and the promiscuous group, and isolated can only talk with promiscuous (not even other members in the isolated group!)

Traditionally, if I had two servers in the the same subnet and same vlan, I may have had to create firewall rules to stop traffic or some other means.  Maybe reconfigure the network or addressing.  Maybe not such a big deal, but what if I added 10 more servers.  50 more servers?  Rules and firewall configuration could get kinda hairy.

Using PVLANs in vSphere, I would create the PVLAN, PVLAN groups, and then create the port group associated with the PVLAN groups.  Then, assign the VM to the required port group. In our case, infrastructure servers like the Domain controller were set to the promiscuous group.  But, we wanted to restrict traffic between all RDS servers, which were assigned to the Isolated group.

I will note that the behavior of PVLANs can be achieved through other means, depending on what exactly your trying to accomplish.  Also, they are not a replacement for firewall rules in most cases, you will still want to restrict traffic as needed to those VMs in the promiscuous group.  However, PVLANs seem to be a great broad solution and should be considered to augment such designs.

 

J

james gonzales / March 29, 2016 / Networking, Virtualization, vmware / 0 Comments

Google Mail to Office 365 Migration

Office 365 has made email migration pretty simple.  In most cases, you just set a migration endpoint, enter in the mailbox/passwords in a batch and away you go.  https://support.office.com/en-us/article/Migrate-Google-Apps-mailboxes-to-Office-365-665dc56c-581c-4e35-8028-6bc1e8497016

With that said, migrating from Gmail can be a little bit of a headache.  I understand there are security needs to be addressed, and we can never be too safe.  However, I did get the feeling that what needed to happen to achieve a successful migration (not using 3rd party tools) seems a bit superfluous.

1) Gmail can have an admin account that controls some settings for users.
2)The admin account needs to allow two-factor authentication globally. This is just a toggle switch
3)Individual users needed to set up two factor authentication individually. (this tied their email to a phone, what if the user doesn’t want to tie a work gmail account to a personal phone?).   If the global toggle setting was turn off, users could not configure this setting. https://www.google.com/landing/2step/
4) IMAP needed to be enabled for all users individually (did not see a global setting for this). By default, IMAP is disabled.
5) Gmail considers Outlook/Exchange as an “unsecured” program. Therefore, a special app password needs to be created for each user. This is a one time use password that is per application.

5a) You can permit google to allow “unsecured” programs.  But this only halfway works. If the computer is an untrusted computer, the connection to the mailbox via Outlook will still fail.
6) If using the Office 365 migration wizard https://support.office.com/en-us/article/Migrate-Google-Apps-mailboxes-to-Office-365-665dc56c-581c-4e35-8028-6bc1e8497016 , IMAP does not transfer contacts and calendar items.

There were two methods to move over email.
1)Tie their Outlook to their gmail account and export/import psts into their O365 account.
2)Use the migration wizard in O365 to connect to mailboxs directly.

This means that we can do through the manual process of two factor authentication, imap setting, and app password to tie the mailbox to outlook.  Once that’s done your golden, do a export/import and your done.  But, have to do it ad nauseum.

Or, we do it the O365 way with a migration endpoint, and have to do the same thing (sorta), but end up with contact and calendar items not syncing.

Thoughts:  While I agree that we do need these settings, it would be nice if it was easier and less hoops to jump through.  Maybe, a time limited “Deployment Toggle” in which IMAP is allowed for all users, and connections from unsecured apps (or allow Outlook) is allowed.   I imagne contacts and calendar items not syncing may be a limitation of IMAP, but there needs to be a way to mass export import.  That could cause some serious headaches with a user base in the double digits.

It’s no wonder 3rd party apps for things like email migration still have to exist.

Happy troubleshooting,

J

 

james gonzales / March 7, 2016 / Uncategorized / 0 Comments

Recover VM’s from a permanently down XenServer host.

 

We recently had a XenServer node crash to the point it was not possible to recover.

The VM’s that had been operating on the host were no longer visible in XenCenter and had seemingly disappeared.

The first you need to do is locate the UUID of the down host with

 

 

 

Then display a list of all the VM’s on the failed host with

This will output all the VM’s on that host and indicate that they are in a “running” state.

We need to reset the powerstate of each VM.

Once you run this command you will notice the VM appear in XenCenter.  You will more than likely not be able to start the VM due to the VDI being in use by the downed host.

you’ll need to reset the locks on the VDI, this can be done by forgetting the UUID of the VDI and reattaching it to the VM.

One way to do this is to run

 

This will gernate an error but more importanly it will also tell you the UUID of the VDI that is in use.

Then you need to “forget” the VDI

 

this will cause the VM to “lose” the disk, rescan the SR and you’ll see the disk without a VM.

Go to the storage tab of the VM and reattach the VDI and then restart the VM either with XenCenter or

 

note: if the VM has more than one disk youll need to repeat the process of running

 

and each time it will show you the VDI causing the issue.

 

There is a way to reset the VDI’s on a given SR as the above can be time consuming with a large number of virtual machines but this post will not cover that method.

 

 

 

casey jones / March 7, 2016 / Citrix, Virtualization, XenServer / 0 Comments