On Wed, Sep 02, 2020 at 06:26:02PM +0200, Thomas Huth wrote:
> On 07/08/2020 18.22, Thomas Huth wrote:
> > On 20/07/2020 12.22, Thomas Huth wrote:
> >> qemuAgentFSInfoToPublic() currently only sets the devAlias for PCI devices.
> >> However, the QEMU guest agent could also provide the device name
On 07/08/2020 18.22, Thomas Huth wrote:
> On 20/07/2020 12.22, Thomas Huth wrote:
>> qemuAgentFSInfoToPublic() currently only sets the devAlias for PCI devices.
>> However, the QEMU guest agent could also provide the device name in the
>> "dev" field of the response for other devices instead
On 20/07/2020 12.22, Thomas Huth wrote:
> qemuAgentFSInfoToPublic() currently only sets the devAlias for PCI devices.
> However, the QEMU guest agent could also provide the device name in the
> "dev" field of the response for other devices instead (well, at least after
> fixing another problem in
On 20/07/2020 12.32, Daniel P. Berrangé wrote:
> On Mon, Jul 20, 2020 at 12:22:33PM +0200, Thomas Huth wrote:
>> qemuAgentFSInfoToPublic() currently only sets the devAlias for PCI devices.
>> However, the QEMU guest agent could also provide the device name in the
>> "dev" field of the response for
On Mon, Jul 20, 2020 at 12:22:33PM +0200, Thomas Huth wrote:
> qemuAgentFSInfoToPublic() currently only sets the devAlias for PCI devices.
> However, the QEMU guest agent could also provide the device name in the
> "dev" field of the response for other devices instead (well, at least after
>
qemuAgentFSInfoToPublic() currently only sets the devAlias for PCI devices.
However, the QEMU guest agent could also provide the device name in the
"dev" field of the response for other devices instead (well, at least after
fixing another problem in the current QEMU guest agent...). So if creating