How do I construct variable length input (VIL) in a block cipher mode? I've just been skimming NIST's "Five Confidentiality Modes". I understand those block cipher modes are used to securely encrypt input longer that the block cipher length. However, the common block cipher modes all assume my input length is evenly divisible by my block cipher length.

What is a recommended way to deal with my non-block-cipher-length-divisible input to safely encrypt it? Are implementors prepadding it using data length? Or are there other common block cipher mode standards that deal with this?
In the document Five Confidentiality Modes, in section 5.2 it says:


  For the ECB and CBC modes, the total number of bits in the plaintext
  must be a multiple of the  block size, $b$; in other words, for some
  positive integer $n$, the total number of bits in the plaintext  must be
  $nb$


...


  For the CFB mode, the total number of bits in the plaintext must be a
  multiple of a parameter,  denoted $s$, that does not exceed the block
  size; in other words, for some positive integer $n$, the  total number
  of bits in the message must be $ns$


...


  For the OFB and CTR modes, the plaintext need not be a multiple of the
  block size. Let $n$ and $u$  denote the unique pair of positive integers
  such that the total number of bits in the message is  $(n-1)b+u$, where
  $1≤ u≤ b$.


So we can see that for three of the five confidentiality modes, ECB, CBC and CFB respectively, some sort of plaintext padding scheme is called for. But for two of five modes, OFB and CTR respectively, no such padding scheme is needed. However you still operate on 128 bit blocks of data in these modes.

In OFB and CTR modes, if you have a single message that is shorter than the block size, you still encrypt 128 bit blocks of data, but you may not use all 128 bits since you are XORing your plaintext with the cipher output, so you only end up with the number of bits in your smaller message.

See Message lengths with AES CTR mode?