The key term here is iSCSI. Let me say right off of the bat I never liked software initiator iSCSI so you will get a lot of bias from me against it.
There are a few reasons I would not recommend a P2V here:
1) Anything to do with SQL and migrations/upgrades/restores/backups etc. should be done within the context of SQL whether it is sql 2000 or the latest and greatest. Do remember, everything with sql is transactional and therefore when data is moved around without a transactional query involved, you risk database corruption.
2) Again, software initiator iSCSI. It leaves a bad taste just like software RAID did. Because I assume you are dealing with a provisioned volume on a SAN with this system accessing it via a software iSCSI initiator, there are many moving pieces involved when you do a P2V. Even if you shut down your services, dismount the session, you are still dealing with OSS level components "remembered" by the disk subsystems. When the P2V operation is running, it brings these things over and tries to reorganize them inside of the virtual machine. It will work, however, when you remount that session whether it is through the software iscsi initiator or and RDM, you you greatly risk corrupting the file allocation tables that love on that volume. In fact, because to the OS, it looks like a spindle, you could possibly initiate the dirty bit on the physical sector zero of the RAID set and corrupt everything else on that physical array. I have seen similar things happen when old OS's (windows 2000 and windows 2003 do a dirty shut down and turn the dirty bit on causing havoc on entire spindles.
I am not a DBA but have done enough sql migrations to know that you should start with a new server, new sql instance and use the migration tools Microsoft provides. Hope this helps!