On Mon, Oct 31, 2011 at 10:13:36PM +0200, Pasi Kärkkäinen wrote:
Hello,
While testing Fedora 16 Xen PVHVM guests I noticed the following problem:
When starting F16 PVHVM guest I can see the vifX.0 and tapX.0 interfaces appear on dom0, but after the guest kernel (Linux 3.1.0) starts and loads PVHVM drivers the vif/tap interfaces disappear from dom0.. so the bridge in dom0 doesn't have any vifs/taps connected to it anymore.
Has anyone seen that behaviour?
I bet that's also the reason why eth0 inside the PVHVM guest has a MAC address with only zeroes in it: 00:00:00:00:00:00.
If I disable PVHVM with "xen_platform_pci=0" in the domain cfgfile then network for the guest works OK using the qemu-dm emulated nic.
PVHVM guest cfgfile:
<snip>
Some output from inside the PVHVM guest:
# ifconfig eth0 eth0 Link encap:Ethernet HWaddr 00:00:00:00:00:00 BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
<snip>
Full PVHVM guest kernel (Linux 3.1.0) dmesg attached to this email. Some parts of the guest dmesg here:
$ egrep -i 'xen|vif' xen-4.1.2-f16pvhvm-linux-3.1.0-dmesg.txt
<snip>
dom0 kernel (Linux 3.1.0 aswell) messages:
<snip>
"xm log" doesn't have any errors. Any ideas how to fix this? Why do the vif/tap devices disappear from dom0?
Well.. it was actually as simple as removing "type=ioemu" from the vif line. Working vif-example for Xen PVHVM Linux guest VM:
vif = [ 'mac=00:16:5f:03:01:15, bridge=virbr0, model=e1000' ]
So uhm.. when enabling PVHVM there's no need to modify the disk line, but you need to modify the vif-line.. is that like it should be ?
-- Pasi
On Mon, Oct 31, 2011 at 10:51:34PM +0200, Pasi Kärkkäinen wrote:
On Mon, Oct 31, 2011 at 10:13:36PM +0200, Pasi Kärkkäinen wrote:
Hello,
While testing Fedora 16 Xen PVHVM guests I noticed the following problem:
When starting F16 PVHVM guest I can see the vifX.0 and tapX.0 interfaces appear on dom0, but after the guest kernel (Linux 3.1.0) starts and loads PVHVM drivers the vif/tap interfaces disappear from dom0.. so the bridge in dom0 doesn't have any vifs/taps connected to it anymore.
Has anyone seen that behaviour?
I bet that's also the reason why eth0 inside the PVHVM guest has a MAC address with only zeroes in it: 00:00:00:00:00:00.
If I disable PVHVM with "xen_platform_pci=0" in the domain cfgfile then network for the guest works OK using the qemu-dm emulated nic.
PVHVM guest cfgfile:
<snip>
Some output from inside the PVHVM guest:
# ifconfig eth0 eth0 Link encap:Ethernet HWaddr 00:00:00:00:00:00 BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
<snip>
Full PVHVM guest kernel (Linux 3.1.0) dmesg attached to this email. Some parts of the guest dmesg here:
$ egrep -i 'xen|vif' xen-4.1.2-f16pvhvm-linux-3.1.0-dmesg.txt
<snip>
dom0 kernel (Linux 3.1.0 aswell) messages:
<snip>
"xm log" doesn't have any errors. Any ideas how to fix this? Why do the vif/tap devices disappear from dom0?
Well.. it was actually as simple as removing "type=ioemu" from the vif line. Working vif-example for Xen PVHVM Linux guest VM:
vif = [ 'mac=00:16:5f:03:01:15, bridge=virbr0, model=e1000' ]
So uhm.. when enabling PVHVM there's no need to modify the disk line, but you need to modify the vif-line.. is that like it should be ?
It seems "type=ioemu" is not required for anything.. not even for normal HVM emulated nics.
So this works for both normal HVM and PVHVM: vif = [ 'mac=00:16:5f:03:01:15, bridge=virbr0, model=e1000' ]
And control the HVM/PVHVM mode with: xen_platform_pci=1 or xen_platform_pci=0
-- Pasi