AES-CTR uses a nonce - a number used once - rather than an IV for creating the initial counter value. This nonce is actually just an octet stream / byte array rather than a number; you could think of it as an encoded unsigned number.
So in principle, CTR mode doesn't require an IV. However, as there are many ways of creating the initial counter value, most implementations simply allow the user to provide it for them. This then is usually called "the IV", as it is called that in other modes of operation such as CBC.
Generally however the full IV is not random; only the first (leftmost) bytes that are part of the nonce are random, if the a random nonce is used at all.
For example, I'm using AES-CTR.
As each mode uses the IV differently, I'll just focus on AES-CTR.
I use fixed (random generated) key and random IV.
So that's a bad idea, I would only randomize part of the IV if CTR mode is used. Using a random key is fine of course.
I know that I have to encrypt key but I don't know about IV.
You only encrypt a key if you need to establish a key with a receiver and store it with the ciphertext, or to protect it locally. But in the end, you cannot encrypt all keys as every encryption will require another key...
You should never ever encrypt an IV and include it in your question. In AES-CTR the encrypted IV would be identical to the first block of the generated key stream that is XOR'ed with the first plaintext block. If you XOR the encrypted IV with the first ciphertext block you would get back the plaintext block. Never-ever encrypt the IV with the key used for the cipher mode itself.
If I will encrypt 1 block of data with fixed key and first IV.
For AES-CTR the IV will be the first counter block, as indicated in the first part of my answer. There is only one Initialization Vector per message. So there is no such thing as a "first IV" - and definitely not a "second IV".
then encrypt another block of data with fixed key and second IV
The definition of AES-CTR is that you encrypt the next block of data with the second counter block value, and then XOR it with the plaintext.
If you mean a block of data from a second message, then encrypting with a second random IV is likely secure, but see the description above w.r.t. creating the IV values and remind yourself that collisions may occur if you encrypt many messages this way, as random IVs are vulnerable to the birthday problem (i.e. you may get a collision sooner than you would generally expect).
- does this violate the security of AES-CTR?
So no, unless...