Trending Topics

VMware on AWS - How to restore NSX DFW firewall rules to previous state

Image
Customers who uses NSX day-in, day-out would like to have a point-in time restore functionality of DFW firewall rules. Many customer have a large footprints in VMC and make changes to DFW quite often. This feature was missing for long time and we could see its included in recent versions . Let's see how DFW configuration roll back works  NSX DFW configuration has versioning, and it is stored in the NSX Manager.  Every time when someone update DFW configuration, NSX creates one more version but keep storing the previous ones. You can rollback for previous config but reapplying it once again.  You can find the options under Networking & Security tab , > Security > Distributed Firewall . In the right side we see an Actions drop down. Choose View to get to the below screen.  Let’s go through the use case:  1. Original state- default config with no custom rules:  a. There are no saved configurations during last 30 days: In my existing test setup, with the current setting

RHEL server LUN paths goes offline during failover




Description of problem:

Client is attempting to kickstart RHEL5 to a blade system with SAN attached
storage. The customer is hitting an issue where anaconda complains with the
following message at the beginning of the install:

On virt console 1:
Warning: /dev/sda is a read-only filesystem and hit OK to continue

On virt console 3:
parted exception: Warning: Unable to open /dev/sda read-write
(Read-only file system). /dev/sda has been opened read-only

The customer has to hit OK to accept this and the installation will then
complete successfully.

There are currently two LUNs presented from the SAN to the host. /dev/sda is
indeed read-only and apparently it is a gatekeeper type device that is
exported/presented to numerous hosts hence why it's read-only. /dev/sdb is the
second LUN device that we want to install to.

I've tried using the following entries in the kickstart file:
ignoredisk --drives=sda
clearpart --all --drives=sdb
partition /boot --fstype=ext3 --size=200 --ondisk=sdb
partition pv.03 --size=1 --grow --ondisk=sdb
<and create vg and lv......>

And removing the zerombr reference but the customer is still hitting the issue.

How reproducible:
1. Install via kickstart or manual
2. Kickstart profile uses 'ignoredisk=sda' to ignore first LUN
3. Still prompted by anaconda that sda is read-only
4. Hitting Ok or Ignore will continue the installation
Version-Release number of selected component (if applicable):

Steps to Reproduce:
1. Install via kickstart or manual
2. Kickstart profile uses 'ignoredisk=sda' to ignore first LUN
3. Still prompted by anaconda that sda is read-only
4. Hitting Ok or Ignore will continue the installation

Actual results:
User prompted to hit OK when /dev/sda device is found to be read-only

Expected results:
ignoredisk directive in kickstart should indicate which devices to ignore and
not present a warning that it's read-only.



Popular posts from this blog

HOW TO EDIT THE BCD REGISTRY FILE

DNS Scavenging.

AD LDS – Syncronizing AD LDS with Active Directory