Mailing-List: contact dev-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cloudstack.apache.org
Received-SPF: pass (athena.apache.org: domain of p.pawit@gmail.com designates
 209.85.214.182 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAJA5wJRyA7UPy_pgje29+yV8Cy=wHNnxrpk_6kWeVb8u4dZDpA@mail.gmail.com>
References: 
 <CAJA5wJRyA7UPy_pgje29+yV8Cy=wHNnxrpk_6kWeVb8u4dZDpA@mail.gmail.com>
Date: Thu, 20 Jun 2013 13:37:56 +0900
Message-ID: 
 <CAJA5wJRpSkNS_q3kGZ6QNZ2bXF8FzR5X-b_uQ4ee_ZG9Eq9x+w@mail.gmail.com>
Subject: Re: PCI-Passthrough with CloudStack (Improved)
From: Pawit Pornkitprasan <p.pawit@gmail.com>
To: dev@cloudstack.apache.org
Cc: Ryousei Takano <takano-ryousei@aist.go.jp>,
 Pawit Pornkitprasan <p.pawit@gmail.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Hi,

I've forgot to describe the detach-attach mechanism, so I'll describe
it in this reply.

PCI Device detach is done automatically by the agent when a
MigrateCommand is processed. In KVM case, the server gets a list of
attached PCI devices from libvirt's XML and detach very device. If
detach is not successful (i.e. the guest does not have the acpiphp
module loaded), libvirt will error out and the migration will be
canceled.

For re-attachment: Before the migration start, a PCI Device on the new
host is assigned by PciDeviceManager and the one on the old host is
freed (also on state change event). After the migration is successful,
PciDeviceManager sends AttachPciDevicesCommand to the new agent with a
list of the PCI IDs on the new host and the agent orders libvirt to
attach it based on the command.

Best Regards,
Pawit

On Thu, Jun 20, 2013 at 1:12 PM, Pawit Pornkitprasan <p.pawit@gmail.com> wr=
ote:
> Hi,
>
> Following my previous post about implementing PCI Passthrough on
> CloudStack (KVM), I have taken Edison Su=92s and others=92 comments into
> account and came up with an improved design.
>
> Because the devices available at each agent may be different, the
> available devices for passthrough are now configured at the agent
> configuration file (/etc/cloudstack/agent/agent.properties).
> Configuration is a comma separated list of available PCI devices and
> its given name.
>
> pci.devices=3D28:00.1|10GE,28:00.2|10GE,28:00.3|10GE,28:00.4|10GE,28:00.5=
|10GE,28:00.6|10GE,28:00.7|10GE,28:01.0|10GE
>
> At agent startup, the list of PCI devices is parsed and sent together
> with StartupRoutingCommand (in a new field, not in details). The
> management server then stores it in a new table =93op_host_pci_devices=94=
.
> If a device is added, removed, or renamed, the table is updated
> accordingly. The current schema has the following fields
>
> id (auto-increment)
> host_id (host that this device belongs to)
> name (given name of the PCI device)
> domain (PCI ID - domain)
> bus (PCI ID - bus)
> slot (PCI ID - slot)
> function (PCI ID - function)
> instance_id (ID of the VM using the PCI device, NULL if not in use)
>
> The =93name=94 of the PCI device is what is used to assign a device. In a
> compute offering, the user can specify the name of one or more PCI
> devices (as a comma-separated list) and CloudStack will find a host
> with the PCI device of the specified name available and assign it.
>
> A new manager, PciDeviceManager, is then created to handle the
> allocation of PCI device. The manager implements StateListener and
> assigns PCI devices on state change to =93starting=94 and also release th=
e
> devices VM stop. First fit allocator and first fit planner are also
> modified to check for PCI device availability accordingly.
>
> For migration, there are 2 approaches. The first approach is to forbid
> migration and is straightforward. The second approach is to PCI
> Hotplug to detach the device, migrate and attach it again at the other
> end. This will interrupt whatever is using the device on the VM.
> However, it may be desirable for networking devices where the VM can
> use a bonding device to channel network traffic through a standard
> virtualized network device while the PCI Passthrough device is down.
>
> The design mentioned here (including detach-attach migration) has been
> implemented in code and is working. Again, comments and suggestions
> are welcomed.
>
> Best Regards,
> Pawit