(In reply to comment #2)
> Yeah, I tried that too.
>
> I added the 'serial' cmdline argument in the kickstart (refer below), to no
> avail.
>
> --append="console=tty0 console=ttyS0,115200 rd_NO_PLYMOUTH serial text"
This line in kickstart only tells anaconda what parameters should the bootloader use once the system is installed.
What Chris meant in comment 1 was adding "serial" to the kernel boot line before booting anaconda.

If it helps, I've run into exactly the same problem, pulling down 3.1.0-0.rc10.git0.1.fc16.x86_64 from JAIST.
virt-install command used:
virt-install -p -r 512 -n rawhide -f /dev/vg_caesium_domUs/rawhide-boot -f /dev/vg_caesium_domUs/rawhide-root -f /dev/vg_caesium_domUs/rawhide-home -f /dev/vg_caesium_domUs/rawhide-swap -l ftp://ftp.jaist.ac.jp/pub/Linux/Fedora/development/16/x86_64/os/ -x serial,ks="http://hydrogen/~kyl191/ks/ks.php?hostname=rawhide"
If I read comment 3 correctly, I've got 'serial' in the right place. Not much difference though - My last few messages are only slightly different:
Started udev Wait for Complete Device Initialization.
Starting Software RAID Monitor Takeover...
Started anaconda performance monitor.
Starting System Logging Service...
Starting Shell on tty2...
Started Shell on tty2.
Starting Shell on hvc1...
Started Shell on hvc1.
Starting Anaconda version 16.22.
Essentially, no mention of setfilecon, or virtio ports, but I've got hvc1 instead. Also, Anaconda version 16.22.
Also, this output was the same without 'serial' in the kernel boot line.

This is weird. Running it through virt-manager, it boots, complains about my kickstart file "not having a closing quotation", then goes into the normal install.
So the freeze seems to be limited to the console somehow. I'm testing --vnc next.
Now I've got to figure out why my kickstart file passes in pykickstart-1.82-1.fc15, but fails in pykickstart-1.99.4-1.fc16 too.

Er... I did virt-install ... -x serial,ks="...", so it should have passed through to the install.
I'm just wondering if it's my system. I'm going to try doing a virt-install of F16 on my known-working F14 system, and try doing virt-installs of F14/15 on the F16 system.
I'm on call at work for the next 2 days so I won't be able to try until then though.

(In reply to comment #11)
> Er... I did virt-install ... -x serial,ks="...", so it should have passed
> through to the install.
Well and this one misses the 'console=ttyS0,112500' part. This is what your extra args should look like:
--extra-args="ks=file:/fed.ks console=ttyS0,115200 serial"

(In reply to comment #12)
> Well and this one misses the 'console=ttyS0,112500' part. This is what your
> extra args should look like:
>
> --extra-args="ks=file:/fed.ks console=ttyS0,115200 serial"
Er...
I'm not the guy who needed that config - I came in in comment 4, after you posted that.

Ok, as an additional data point, virt-install of f16 from JAIST fails on a f14 host too. Trying an f15 install on the same system works though, so it looks (to me) like something's up with f16 interacting with virt-install (since using virt-manager works).
One question - F15 uses 'hvc0', while F16 is using 'hvc1'. Is that significant? I've tried using console=hvc0 in the boot line, but that didn't work/change anything obvious.

(In reply to comment #16)
> Wait wait wait. I'm running this on a Xen hypervisor.
>
> Does "Looking for the virtio ports... done." imply use of KVM?
It does, it means we found the string "QEMU virtual CPU" in /proc/cpuinfo.

Kyle - the problem lines in your kickstart file are:
echo "# Added by Kickstart install options
%wheel ALL=(ALL) ALL" >> /etc/sudoers
I guess pykickstart doesn't like the fact that it's split over lines, but it shouldn't be attempting to parse lines inside a script like this anyway. I'll take a look. Also, I don't think I can generate a better error message there. I'm just getting a ValueError and reprinting it.

Ales, and rest: Sorry for this late response, I was drowned w/ a torrent of other bugs and lost track of this.
From comment #9, seems like it works for you.
I just retried with the latest qemu-kvm and it works now for me.
==================
[root@moon ~]# uname -r ; rpm -q qemu-kvm libvirt python-virtinst
3.1.0-0.rc9.git0.0.fc16.x86_64
qemu-kvm-0.15.1-3.fc16.x86_64
libvirt-0.9.6-2.fc16.x86_64
python-virtinst-0.600.0-5.fc16.noarch
[root@moon ~]#
================
But, access to serial console seems to be distorted. While I type password, it just escapes the prompt and throws error(I'm seeing this behaviour for f16 guests as well.
In a previous discussion w/ Ray Strode, he identified that plymouth was interfering. So I disable it pretty much using the rd_NO_PLYMOUTH option.
(though this is not be related to this bug. I think the current bz can be closed if there are no objections)
================================================
[root@moon ~]# virsh console pkifedora1
Connected to domain pkifedora1
Escape character is ^]
Fedora release 16 (Verne)
Kernel 3.1.0-7.fc16.x86_64 on an x86_64 (ttyS0)
dhcp201-193 login: root
Password:
Login incorrect
login:
Password:
Login incorrect
login:
================================================
Ales, can you please post your working version of kernel, qemu-kvm libvirt python-virtinst ? Just for comparison?

(In reply to comment #23)
> (though this is not be related to this bug. I think the current bz can be
> closed if there are no objections)
no objections from me.
>
> Ales, can you please post your working version of kernel, qemu-kvm libvirt
> python-virtinst ? Just for comparison?
These are mine versions:
python-virtinst-0.600.0-5.fc16.noarch
qemu-kvm-0.15.1-1.fc16.x86_64
libvirt-0.9.6-2.fc16.x86_64
I never tested entering password in plymount via serial console so these won't guarantee anything.