similar to: support for live migration with PCI passthrough devices

On Tue, Aug 25, 2020 at 02:56:49PM +0200, Michal Privoznik wrote: > On 8/25/20 1:40 PM, Henry lol wrote: > > Hi guys, > > > > I'm wondering whether libvirt supports live migration for the VM with > > PCI passthrough devices. > > or it must be assumed before live migration that all passthrough devices > > be unplugged? > > Unfortunately, this is

Hi guys. These days I'm doing research on SR-IOV & Live migration. As we all know there is big problem that SR-IOV & Live migration can not exist at the same time. I heard that KVM + SRIOV + MacVtap can solve this problem. So I want to try. My environment: Host: Dell R610, OS: RHEL 6.4 ( kernel 2.6.32) NIC: intel 82599

Hi, I’m an openstack developer trying to use Assignment from a pool of SRIOV VFs in a libvirt <network> definition from this link http://wiki.libvirt.org/page/Networking My question is is it possible for nova (the openstack compute) to know which VF out of the pool will be allocated to a VM before it invokes libvirt to launch it? Thanks In advance, Robert

I can see from different post that if working with sr-iov, i should work with vlan Is this an obligation to work with vlan if working with sr-iov? If not according to which parameter will the different vf get the traffic. Let's say i declare max_vfs=7, how will the traffic be seperated between the vm? However till i get an answer i tried to work with vlan And i still don't get

On Thu, 30 Nov 2017 15:54:40 +0200, Michael S. Tsirkin wrote: > On Wed, Nov 29, 2017 at 07:51:38PM -0800, Jakub Kicinski wrote: > > On Thu, 30 Nov 2017 11:29:56 +0800, Jason Wang wrote: > > > On 2017?11?29? 03:27, Jesse Brandeburg wrote: > > > > Hi, I'd like to get some feedback on a proposal to enhance virtio-net > > > > to ease configuration of a

On Thu, 30 Nov 2017 15:54:40 +0200, Michael S. Tsirkin wrote: > On Wed, Nov 29, 2017 at 07:51:38PM -0800, Jakub Kicinski wrote: > > On Thu, 30 Nov 2017 11:29:56 +0800, Jason Wang wrote: > > > On 2017?11?29? 03:27, Jesse Brandeburg wrote: > > > > Hi, I'd like to get some feedback on a proposal to enhance virtio-net > > > > to ease configuration of a

On Thu, 30 Nov 2017 11:29:56 +0800, Jason Wang wrote: > On 2017?11?29? 03:27, Jesse Brandeburg wrote: > > Hi, I'd like to get some feedback on a proposal to enhance virtio-net > > to ease configuration of a VM and that would enable live migration of > > passthrough network SR-IOV devices. > > > > Today we have SR-IOV network devices (VFs) that can be passed

On Thu, 30 Nov 2017 11:29:56 +0800, Jason Wang wrote: > On 2017?11?29? 03:27, Jesse Brandeburg wrote: > > Hi, I'd like to get some feedback on a proposal to enhance virtio-net > > to ease configuration of a VM and that would enable live migration of > > passthrough network SR-IOV devices. > > > > Today we have SR-IOV network devices (VFs) that can be passed

On 03/10/14 17:15, Laine Stump wrote: > On 10/03/2014 11:38 AM, lejeczek wrote: >> hi everybody >> >> I'd presume virsh makes the best possible choice, right? >> It is that just seems bit... odd having realtek in guest and Intel's >> VF on host, no? > This can safely be ignored - in the case of an SRIOV VF that is assigned > to the guest using PCI

On 8/25/20 1:40 PM, Henry lol wrote: > Hi guys, > > I'm wondering whether libvirt supports live migration for the VM with > PCI passthrough devices. > or it must be assumed before live migration that all passthrough devices > be unplugged? Unfortunately, this is still not supported. The problem is that PCI devices themselves are not capable of dumping their internal

Hi laine, I have leave some questions on IRC, but my VPN broken time after time. Please ignore the questions on IRC. In my understanding, the standby and primary hostdev interface may be in different subnet. I'm not sure whether it is correct. Could you please help to explain? Thank you in advance. For example, primary hostdev is connected to vf-pool with <pf='eth0'/>, while

hi everybody I'd presume virsh makes the best possible choice, right? It is that just seems bit... odd having realtek in guest and Intel's VF on host, no? regards

Hi Laine, For the feature testing before, I only test the linux bridge setting as in 2), it works. Now I tried 1), to use macvtap bridge mode connected to the PF, it can not work as the hostdev interface can not get dhcp ip address on the guest. Check on host, the /var/log/messages and dmesg both says: "Jul 6 04:54:45 dell-per730-xx kernel: ixgbe 0000:82:00.1 enp130s0f1: 1 Spoofed packets

On 2020-07-06 10:01, Laine Stump wrote: > On 7/6/20 5:10 AM, Yalan Zhang wrote: > > > > Hi Laine, > > > > For the feature testing before, I only test the linux bridge setting as > > in 2), it works. > > Now I tried 1), to use macvtap bridge mode connected to the PF, it can > > not work as the hostdev interface can not get dhcp ip address on the >

Hi, trying to pass through a intel x520 VF on a Dell R620, I''m getting in domU: [ 58.162639] pci 0000:00:00.6: address space collision: [mem 0xd500c000-0xd500ffff 64bit pref] conflicts with System RAM [mem 0x00100000-0x176ffffff] [ 58.162654] pcifront pci-0: Could not claim resource 0000:00:00.6/0! Device offline. Try using e820_host=1 in the guest config. and in dom0 (XEN)

Hi all, I'm testing on debian/unstable SR-IOV feature with Broadcom BCM57810 cards and KVM hypervisor: Compiled against library: libvirt 1.2.1 Using library: libvirt 1.2.1 Using API: QEMU 1.2.1 Running hypervisor: QEMU 1.7.0 bnx2x -> firmware 7.8.17 -> driver from kernel 3.12.7 8 VFs are created on the first PF. For each VF, a specific mac address is set manually using "ip

On 7/8/20 10:02 AM, Ken Cox wrote: > > On 7/8/20 1:30 AM, Stefan Assmann wrote: >> On 2020-07-06 10:01, Laine Stump wrote: >>> On 7/6/20 5:10 AM, Yalan Zhang wrote: >>>> Hi Laine, >>>> >>>> For the feature testing before, I only test the linux bridge setting as >>>> in 2), it works. >>>> Now I tried 1), to use

On Tue, Dec 05, 2017 at 11:59:17AM +0200, achiad shochat wrote: > Then we'll have a single solution for both netvsc and virtio (and any > other PV device). > And we could handle the VF DMA dirt issue agnostically. For the record, I won't block patches adding this kist to virtio on the basis that they must be generic. It's not a lot of code, implementation can come first,

On Tue, Dec 05, 2017 at 11:59:17AM +0200, achiad shochat wrote: > Then we'll have a single solution for both netvsc and virtio (and any > other PV device). > And we could handle the VF DMA dirt issue agnostically. For the record, I won't block patches adding this kist to virtio on the basis that they must be generic. It's not a lot of code, implementation can come first,

Hi, I'd like to get some feedback on a proposal to enhance virtio-net to ease configuration of a VM and that would enable live migration of passthrough network SR-IOV devices. Today we have SR-IOV network devices (VFs) that can be passed into a VM in order to enable high performance networking direct within the VM. The problem I am trying to address is that this configuration is generally