[libvirt] troubles creating an OVS network with xen, libxl and libvirt.
One more quirk I can create a domain using the lx commands and a slightly modified .conf file. "virsh start kvmtest" returns a failure. I tracked the information passed to vif-openvswitch and it is being called with type_if=tap and it needs to be type_if=vif. Any help would be greatly appreciated once again. -- Alvin Starr || voice: (905)513-7688 Netvel Inc. || Cell: (416)806-0133 alvin@netvel.net ||
Alvin Starr wrote:
One more quirk
I can create a domain using the lx commands and a slightly modified .conf file. "virsh start kvmtest" returns a failure. I tracked the information passed to vif-openvswitch and it is being called with type_if=tap and it needs to be type_if=vif.
Sounds like a Xen bug. Does it call vif-openvswitch twice? Once for an emulated NIC and once for PV nic?
Any help would be greatly appreciated once again.
[...]
name = "kvmtest" uuid = "1883fa66-d052-4bb2-b57a-8571f77ae69e" maxmem = 4096 memory = 4096 vcpus = 3 builder = "hvm" kernel = "/usr/lib/xen/boot/hvmloader" boot = "nc" pae = 1 acpi = 1 apic = 1 hap = 0 viridian = 0 rtc_timeoffset = 0 localtime = 0 on_poweroff = "destroy" on_reboot = "restart" on_crash = "restart" device_model = "/usr/lib64/xen/bin/qemu-dm" usb = 1 usbdevice = "tablet" sdl = 0 vnc = 1 vncunused = 1 keymap = "en-us" disk = [ "phy:/dev/xen_images/kvmtest,hda,w" ] vif = [ "mac=00:16:3e:3f:31:36,bridge=br0,script=vif-bridge,model=e1000" ]
Shouldn't that be '...,script=vif-openvswitch,...'? Also, if your guest has PV drivers, you could set 'model=netfront' to explicitly say you only want the PV NIC. Regards, Jim
parallel = "none" serial = "pty"
On 05/07/2014 01:23 PM, Jim Fehlig wrote:
Alvin Starr wrote:
One more quirk
I can create a domain using the lx commands and a slightly modified .conf file. "virsh start kvmtest" returns a failure. I tracked the information passed to vif-openvswitch and it is being called with type_if=tap and it needs to be type_if=vif. Sounds like a Xen bug. Does it call vif-openvswitch twice? Once for an emulated NIC and once for PV nic? openvswitch is called twice once with ACTION=online and again with ACTION=offline
Any help would be greatly appreciated once again. [...] name = "kvmtest" uuid = "1883fa66-d052-4bb2-b57a-8571f77ae69e" maxmem = 4096 memory = 4096 vcpus = 3 builder = "hvm" kernel = "/usr/lib/xen/boot/hvmloader" boot = "nc" pae = 1 acpi = 1 apic = 1 hap = 0 viridian = 0 rtc_timeoffset = 0 localtime = 0 on_poweroff = "destroy" on_reboot = "restart" on_crash = "restart" device_model = "/usr/lib64/xen/bin/qemu-dm" usb = 1 usbdevice = "tablet" sdl = 0 vnc = 1 vncunused = 1 keymap = "en-us" disk = [ "phy:/dev/xen_images/kvmtest,hda,w" ] vif = [ "mac=00:16:3e:3f:31:36,bridge=br0,script=vif-bridge,model=e1000" ]
Shouldn't that be '...,script=vif-openvswitch,...'? Also, if your guest has PV drivers, you could set 'model=netfront' to explicitly say you only want the PV NIC. Your correct. I hand fixed it and ran my tests but then foolishly reran domxml-to-native overwriting my fixes. I gave various nic configurations a try and e1000 was just the last one before moving to looking for the problem in other places. I will likely use the PV nic for any real systems but now I am just trying to get the kinks out.
Regards, Jim
parallel = "none" serial = "pty"
-- Alvin Starr || voice: (905)513-7688 Netvel Inc. || Cell: (416)806-0133 alvin@netvel.net ||
I have updated the libvirt and xen from the f20 latest updates and forced all the scripts back to their unadulterated state. I believe that I am now seeing libvirt passing a -1 devid to libxl expecting libxl to chose the right one. There was an email thread about this problem. "[libvirt] Setting devid for emulated NICs (Xen 4.3.1 / libvirt 1.2.0) using libxl driver". I read through email chain but I did not see a resolution. On 05/09/2014 10:06 AM, Alvin Starr wrote:
On 05/07/2014 01:23 PM, Jim Fehlig wrote:
Alvin Starr wrote:
One more quirk
I can create a domain using the lx commands and a slightly modified .conf file. "virsh start kvmtest" returns a failure. I tracked the information passed to vif-openvswitch and it is being called with type_if=tap and it needs to be type_if=vif. Sounds like a Xen bug. Does it call vif-openvswitch twice? Once for an emulated NIC and once for PV nic? openvswitch is called twice once with ACTION=online and again with ACTION=offline
Any help would be greatly appreciated once again. [...] name = "kvmtest" uuid = "1883fa66-d052-4bb2-b57a-8571f77ae69e" maxmem = 4096 memory = 4096 vcpus = 3 builder = "hvm" kernel = "/usr/lib/xen/boot/hvmloader" boot = "nc" pae = 1 acpi = 1 apic = 1 hap = 0 viridian = 0 rtc_timeoffset = 0 localtime = 0 on_poweroff = "destroy" on_reboot = "restart" on_crash = "restart" device_model = "/usr/lib64/xen/bin/qemu-dm" usb = 1 usbdevice = "tablet" sdl = 0 vnc = 1 vncunused = 1 keymap = "en-us" disk = [ "phy:/dev/xen_images/kvmtest,hda,w" ] vif = [ "mac=00:16:3e:3f:31:36,bridge=br0,script=vif-bridge,model=e1000" ] Shouldn't that be '...,script=vif-openvswitch,...'? Also, if your guest has PV drivers, you could set 'model=netfront' to explicitly say you only want the PV NIC. Your correct. I hand fixed it and ran my tests but then foolishly reran domxml-to-native overwriting my fixes. I gave various nic configurations a try and e1000 was just the last one before moving to looking for the problem in other places. I will likely use the PV nic for any real systems but now I am just trying to get the kinks out.
Regards, Jim
parallel = "none" serial = "pty"
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
-- Alvin Starr || voice: (905)513-7688 Netvel Inc. || Cell: (416)806-0133 alvin@netvel.net ||
Alvin Starr wrote:
I have updated the libvirt and xen from the f20 latest updates and forced all the scripts back to their unadulterated state. I believe that I am now seeing libvirt passing a -1 devid to libxl expecting libxl to chose the right one.
There was an email thread about this problem. "[libvirt] Setting devid for emulated NICs (Xen 4.3.1 / libvirt 1.2.0) using libxl driver". I read through email chain but I did not see a resolution.
Fixed by the following commit http://libvirt.org/git/?p=libvirt.git;a=commit;h=e1459c1fe88068f231bad254733... Regards, Jim
participants (2)
-
Alvin Starr -
Jim Fehlig