With any virtual appliance, there are some things to consider before deployment, particularly when going into production.

The RAM, CPU, SWAP and DISK configuration should be changed to suit your hardware environment and should be increased for larger deployments. (Please consult your VMware administrator for details on how to do this.)

• CPU - By default the Virtual Appliance is configured with a single CPU. BMC Atrium Discovery can make good use of more than one CPU and it is recommended that you increase the number of CPUS allocated to the VA. For reference the recommended hardware based platform has two quad-core Hyperthreaded CPUs - equivalent to 16 virtual CPUs.
• RAM - It is recommended that the RAM available to the Virtual Appliance is increased.
• SWAP - It is recommended that the swap space be the same size as the amount of RAM.
• DISK - The default 50Gb disk that is configured is suitable for around 150 Operating System Instances (OSI). When scanning larger estates it is recommended that this is increased. For instructions on how to extend the disk space available and recommendations for appropriate sizing see below. Local disk storage with a cache is recommended over SAN or NAS storage due to the nature of the datastore operations which utilize small transactions. Performance will be greatly reduced if a slow disk subsystem is configured.
• Network - Only bridged mode networking is supported.

Dedicated VMware Resources It is strongly recommended that the CPU and RAM resources that are allocated to the ADDM appliance are reserved, and are not shared with other VMware guest OSes. If this is not the case, performance may be inconsistent and not achieve expectations. For more details contact your VMware administrator.

Virtual Appliance sizing guidelines

There are many factors to be taken into consideration when specifying the configuration of the Virtual Appliance. Every environment is different and consequently the data published here is purely a guide as to how to configure your Virtual Appliance.

To aid this process we have defined four "classes" of appliance deployment that broadly follow our experience of how BMC Atrium Discovery is deployed in the field. They are differentiated by the number of Operating System Instances (OSIs) that are being scanned by BMC Atrium Discovery.

The names given to these classes are of use only in this document and do not relate to the various editions that BMC Atrium Discovery is available in.

The classes are:

• Proof of Concept. Small, time-limited test deployments of BMC Atrium Discovery, scanning up to 150 OSIs.
• Baseline. A typical baseline as offered by BMC, scanning up to 500 OSIs.
• Datacenter. A typical large scale deployment, scanning up to 5000 OSIs.
• Consolidated Enterprise. Enterprise scale deployments, typically a Consolidation Appliance taking feeds from many Scanning Appliances. Typically scanning up to 40000 OSIs.

Proof of Concept The Proof of Concept class has minimal storage allowance as they are only intended for a limited period of scanning such as a week long trial. For longer periods or a continuously used development or UAT system, the Baseline class is the minimum recommended.

32 bit appliance memory considerations A 32 bit appliance cannot be used in any deployments requiring more than 4GB RAM. In practice this means that any deployment beyond a proof of concept must use a 64 bit appliance. The memory limit for a 32 bit appliance can be lower than 4GB depending on your environment.

Impact of Appliance Snapshot

The BMC Atrium Discovery Appliance Snapshot feature allows you take a snapshot of the datastore and critical configuration files to facilitate moving the data between appliances.
The process by which the data is packaged means that a considerable overhead of empty disk space is needed to complete the task.

Therefore when providing guidelines for how much disk space to give your Appliance for the database, whether you intend to perform Appliance Snapshots or not is an important choice to make. If you do plan to make use of this feature then you will need to provision considerably larger disks.

Where the following tables refer to CPUs, full use of a logical CPU (core) is assumed. For example, if eight CPUs are required, then you may provide them in the following ways:

• Eight virtual CPUs in your virtualization platform, such as VMWare Infrastructure when deploying a Virtual Appliance.
• Four dual core physical CPUs in hardware when deploying via DVD Kickstart.
• Two quad core physical CPUs in hardware when deploying via DVD Kickstart.

Appliance sizing guidelines

VMware maximums The following are the maximum supported limits for the main deployment platforms. VMware Server v2 - 2 CPUs & 8GB RAM VMware Infrastructure 3.0.2 - 4 CPUs & 16GB RAM VMware Infrastructure 3.5 - 4 CPUs & 65GB RAM VMware Infrastructure 4 - 8 CPUs & 255GB RAM Note that ESX version 4 can support up to 8 vCPUs, earlier versions have a maximum of 4.

Adding storage to hold the database

When deploying a Virtual Appliance into production or at scale it is recommended that you add an additional physical/virtual disk to the system and configure it so that the database resides on this.

An additional benefit is that the two most disk intensive operations of the system, writing the database transaction log files and writing to the database itself, can happen on separate disk spindles hence removing contention.

In order to add additional storage for the BMC Atrium Discovery database you must have administration-level knowledge of BMC Atrium Discovery, VMware and Linux.

This procedure can also be used to add additional storage to a physical appliance. In the following instructions, where you need to shutdown or restart the VA, shutdown and power off, or restart the physical appliance.

To configure a separate database disk, complete the following steps (NOTE: this assumes the datastore will be rebuilt with an empty one):

1. Snapshot (copy) the BMC Atrium Discovery database if required.
2. Shutdown the VA.
3. Add a new SCSI disk or disks.
4. Restart the VA.
5. Stop the tideway services.
6. Partition the new disk.
7. Format the required partition (ext3).
8. Mount the required partition on /mnt/disk2.
9. Ensure that the ownership of /mnt/disk2 is tideway:tideway and is writable by the tideway user.
10. Add /mnt/disk2 to /etc/fstab.
11. Copy /usr/tideway/python/model/link/link_twin_disks.conf to /usr/tideway/etc/link.conf.
12. Reinitialize the tideway model (tw_model_init). This operation activates the installed TKU and may take a long time.
13. Start the tideway services.
14. If necessary, import the snapshot.

Note See tw_model_init for details on the command line utility options to use.

If the datastore is to be moved to the new disk, perform the following steps:

1. Shutdown the VA.
2. Add a new SCSI disk or disks.
3. Restart the VA.
4. Stop the tideway services.
5. Partition the new disk.
6. Format the required partition (ext3).
7. Mount the required partition on /mnt/disk2.
8. Ensure that the ownership of /mnt/disk2 is tideway:tideway and is writable by the tideway user.
9. Add /mnt/disk2 to /etc/fstab.
10. Copy /usr/tideway/python/model/link/link_twin_disks.conf to /usr/tideway/etc/link.conf.
11. Create /mnt/disk2/tideway.db and /mnt/disk2/snapshot
12. Move /usr/tideway/var/localdisk/tideway.db/data to /mnt/disk2/tideway.db/data
13. Move /usr/tideway/var/localdisk/snapshot/snapshots to /mnt/disk2/snapshot/snapshots
14. Move symlink /usr/tideway/var/snapshot/snapshots to point to /mnt/disk2/snapshot/snapshots
15. Move symlink /usr/tideway/var/tideway.db/data to point to /mnt/disk2/tideway.db/data
16. Start the tideway services.

Adding swap space

If you require more swap space, you can do one of the following:

• Add a new disk, format it as a Linux swap, and use the swapon utility to enable it.
• Increase the amount of RAM in the system.