Hi,
I read the design here and I like to make sure that the future road map will expand beyond the current scope.
The current design totally rely on libvirt and does not parse the content of the PCI addressing. That's really really basic. The user should be able to specify pci slot allocation of his devices through the gui. I guess you won't be able to do that w/ the current scheme.
Also, what about devices that can't be hot plug (like qxl)? You need to reveal this info to the user. Currently we have ability in the kvm bios (seabios) to automatically disable the host plug of some critical devices like the vga driver (qxl) and others. The user should be allowed to hot plug/unplug only allowed devices.
You have to make your design work w/ pci bridges since we'll add it to qemu and once there is such VM (management should enable the bridge) there will be more pci devices available to it.
Regards, Dor
-----Original Message----- From: vdsm-devel-bounces@lists.fedorahosted.org [mailto:vdsm-devel- bounces@lists.fedorahosted.org] On Behalf Of Dor Laor Sent: Tuesday, December 13, 2011 10:02 AM To: engine-devel@ovirt.org; vdsm-devel@lists.fedorahosted.org Subject: http://www.ovirt.org/wiki/Features/Design/StablePCIAddresses
Hi,
I read the design here and I like to make sure that the future road map will expand beyond the current scope.
The current design totally rely on libvirt and does not parse the content of the PCI addressing. That's really really basic. The user should be able to specify pci slot allocation of his devices through the gui. I guess you won't be able to do that w/ the current scheme.
We know that the current design is not sufficient. This is exactly the reason why I am working right now on new one that will give abilities to the manager to change PCI addresses per device. But in any case we planning that the first addresses allocation will be done by libvirt and vdsm will return it to the manager. I am not sure whether it will be accessible via GUI. Livnat?
Also, what about devices that can't be hot plug (like qxl)? You need to reveal this info to the user. Currently we have ability in the kvm bios (seabios) to automatically disable the host plug of some critical devices like the vga driver (qxl) and others. The user should be allowed to hot plug/unplug only allowed devices.
You have to make your design work w/ pci bridges since we'll add it to qemu and once there is such VM (management should enable the bridge) there will be more pci devices available to it.
Regards, Dor _______________________________________________ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
On 12/13/2011 11:22 AM, Igor Lvovsky wrote:
-----Original Message----- From: vdsm-devel-bounces@lists.fedorahosted.org [mailto:vdsm-devel- bounces@lists.fedorahosted.org] On Behalf Of Dor Laor Sent: Tuesday, December 13, 2011 10:02 AM To: engine-devel@ovirt.org; vdsm-devel@lists.fedorahosted.org Subject: http://www.ovirt.org/wiki/Features/Design/StablePCIAddresses
Hi,
I read the design here and I like to make sure that the future road map will expand beyond the current scope.
The current design totally rely on libvirt and does not parse the content of the PCI addressing. That's really really basic. The user should be able to specify pci slot allocation of his devices through the gui. I guess you won't be able to do that w/ the current scheme.
We know that the current design is not sufficient. This is exactly the reason why I am working right now on new one that will give abilities to the manager to change PCI addresses per device. But in any case we planning that the first addresses allocation will be done by libvirt and vdsm will return it to the manager. I am not sure whether it will be accessible via GUI. Livnat?
Not sure we'll expose it in the UI/API for editing in the first version, more likely it will be included in a view-only mode and then extended for user manipulations.
Anyway we are working on a more explicit API then a Blob, as Igor wrote.
Livnat
Also, what about devices that can't be hot plug (like qxl)? You need to reveal this info to the user. Currently we have ability in the kvm bios (seabios) to automatically disable the host plug of some critical devices like the vga driver (qxl) and others. The user should be allowed to hot plug/unplug only allowed devices.
You have to make your design work w/ pci bridges since we'll add it to qemu and once there is such VM (management should enable the bridge) there will be more pci devices available to it.
Regards, Dor _______________________________________________ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
On Tue, Dec 13, 2011 at 10:02:24AM +0200, Dor Laor wrote:
Hi,
I read the design here and I like to make sure that the future road map will expand beyond the current scope.
The current design totally rely on libvirt and does not parse the content of the PCI addressing. That's really really basic. The user should be able to specify pci slot allocation of his devices through the gui. I guess you won't be able to do that w/ the current scheme.
Also, what about devices that can't be hot plug (like qxl)? You need to reveal this info to the user. Currently we have ability in the kvm bios (seabios) to automatically disable the host plug of some critical devices like the vga driver (qxl) and others. The user should be allowed to hot plug/unplug only allowed devices.
You have to make your design work w/ pci bridges since we'll add it to qemu and once there is such VM (management should enable the bridge) there will be more pci devices available to it.
The general principle from libvirt is that there are two elements to be tracked, the actual per-device <address> element, and at the VM level one or more <controller> device elements. Currently we don't expose any <controller> devices for PCI, since we only have a single PCI root complex and single PCI bus. We do, however, use <controller> for SCSI, CCID, etc, etc. In the future when we add support for PCI bridges, or PCI root complexes, then we'll add new <controller> devices to represent them.
Regards, Daniel
vdsm-devel@lists.stg.fedorahosted.org