Ahmed, when you say "VIP", do you mean a self-IP, or are you really trying to send the logs through a Virtual Server? If you are sending them through a Virtual Server, what processing is the Virtual Server performing? Is it just load-balancing, or something more?
Ahmed, I suspect there may still be a disconnect. I assume you are not planning to apply ASM policies to the log messages themselves, but rather, a Virtual Server with an ASM policy, an attached pool and iRules is generating logs, and that you want those logs to use a self-IP (and tmm interface) rather than the management (port) IP (and interface) as the source. The self-IP can be the same IP as a Virtual IP or something different, but either way, it's a self-IP. I'm going to operate on this assumption. If you do in fact wish to send logs sourced from the BIG-IP through a Virtual Server on the same BIG-IP, that is quite a bit trickier.
Broadly speaking, there are three log sources from a BIG-IP:
syslog-ng for system logs and the log command in an iRule;
Generally speaking, logging will follow the most specific route, but there are two types of routes on a BIG-IP: management routes (tied to the management plane, i.e., Linux) and tmm routes (tied to the data plane). syslog-ng logs will follow the most specific management route. Usually, tmm routes are redistributed into the managment routing table, but if two routes of equal match length are defined (one in management and one in tmm), the management path will usually win for syslog. Direct HSL logging from an iRule will only follow tmm routes unless the publisher flag is used. Log publishers can use either path.
If you want to coerce your logs to be sourced from a tmm interface, the mechanism depends on how the logs are sourced. Since it is related to a Virtual Server, I'm guessing they come from an iRule via the log command or HSL:: commands, or they are via a Log Publisher. Since it's ASM, I assume it's a configured log publisher. However, would you mind sharing the configuration snippet for the logging?