Hi John, <snip>
> > Subject: [PATCH v3 1/2] doc: live migration of VM with Virtio and VF > > > > This patch describes the procedure to be be followed to perform Live > > Migration of a VM with Virtio and VF PMD's using the bonding PMD. > > > > It includes sample host and VM scripts used in the procedure, and a > > sample switch configuration. > > Hi Bernard, > > Thanks for the doc. It is a complicated process so it is good to have this > detailed how-to. Some comments below. > > > > + > > +Live Migration of VM with SR-IOV VF: > > +==================================== > > > I wouldn't include a colon in the heading. Something like this may be better: Ok, I will remove colons from headings. > Live Migration of a VM with SR-IOV VF > ===================================== > > > > + > > +Live Migration overview for VM with Virtio and VF PMD's: > > +-------------------------------------------------------- > > > Also, I wouldn't include the "Live Migration ... for VM with Virtio ..." > in each heading. The context should be clear from the main sections of the > doc. I this case I would just call the heading "Overview" Ok, will change. > > > + > > +It is not possible to migrate a Virtual Machine which has an SR-IOV > > Virtual Function. > > Add (VF) in brackets at the first mention of Virtual Function here. Also for > PF > below. Ok, I will add (VF) and (PF) > > > +To get around this problem the bonding PMD is used. > > I would add to the end of this paragraph: > > The following sections show an example of how to do this. Ok, will add. > > > Also I think the "Test Setup" header from below should be moved up to this > point. > > > + > > +A bonded device is created in the VM. > > +The virtio and VF PMD's are added as slaves to the bonded device. > > +The VF is set as the primary slave of the bonded device. > > + > > +A bridge must be set up on the Host connecting the tap device, which > > +is the backend of the Virtio device and the Physical Function device. > > + > > +To test the Live Migration two servers with identical operating > > +systems > > installed are used. > > +KVM and Qemu 2.3 is also required on the servers. > > + > > +The servers have Niantic and or Fortville NIC's installed. > > +The NIC's on both servers are connected to a switch which is also > > +connected to the traffic generator. > > I would prefix this paragraph with: "In this example, the servers have Niantic > and .." Ok, will do. > > > > +The switch is configured to broadcast traffic on all the NIC ports. > > + > > +Live Migration with SR-IOV VF test setup: > > +----------------------------------------- > > Just "Test Setup" would be better. And move up, I think. Ok, will do. > > > > + > > +Live Migration steps for VM with Virtio and VF PMD's: > > +----------------------------------------------------- > > Again "Live Migration steps" would be fine. Ok, will change. > > > Also I would change this paragraph to link forward to the scripts like: > > > The sample scripts mentioned in the steps below can be found in the > :ref:`lm_bond_virtio_sriov_host_scripts` > and :ref:`lm_bond_virtio_sriov_host_scripts` sections. > > > And then put the targets in the relevant sections of the docs. > > .. _lm_bond_virtio_sriov_host_scripts: > > .. _lm_bond_virtio_sriov_vm_scripts: > > Ok will do. > > + > > +The host is running the Kernel Physical Function driver (ixgbe or i40e). > > + > > +The ip address of host_server_1 is 10.237.212.46 > > + > > +The ip address of host_server_2 is 10.237.212.131 > > + > > +The sample scripts mentioned in the steps below can be found in the > > +host_scripts and vm_scripts sections. > > + > > +On host_server_1: Terminal 1 > > +^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > The documentation guidelines say to use ~~~~~~ as the third level heading > underline. It doesn't really matter since the RST parsers figure it out. > Up to you if you want to change it. I will leave as is. > > http://dpdk.org/doc/guides/contributing/documentation.html#section- > headers > > > +The following command only works with kernel PF for Niantic > > + > > +.. code-block:: console > > + > > + testpmd> mac_addr add port 1 vf 0 AA:BB:CC:DD:EE:FF > > + > > +create bonded device(mode) (socket) > > Should be a space after device. Ok, will add a space. > Also these lines describing the state or state > change should be written have capital letters and full stops so they read like > sentences. Also, if describing a state change you could add "now" so the > reader is aware of the change. For example: > > - primary is port 1, 2 active slaves > + Primary is now port1. There are 2 active slaves. Ok, will change. > > > + > > +Setup Virtual Machine on host_server_1 > > + > > +.. code-block:: sh > > + > > + #!/bin/sh > > + > > > I thought that the code block had to be indented 3 spaces but the RST > parsers didn't complain. Might be worth changing them anyway to a > consistent 3 or 4 space indent. I think 2 spaces are enough (if I remember correctly) > > John Thanks for the review. Regards, Bernard.
