[libvirt] [PATCH] docs: mention bhyve SATA address changes in news.xml
--- docs/news.xml | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/docs/news.xml b/docs/news.xml index f408293a1..9e3c4ec3d 100644 --- a/docs/news.xml +++ b/docs/news.xml @@ -56,6 +56,22 @@ a fabric name has been removed by making it optional. </description> </change> + <change> + <summary> + bhyve: change address allocation schema for SATA disks + </summary> + <description> + Previously, the bhyve driver assigned PCI addresses to SATA disks directly + rather than assigning that to a controller and using SATA addresses for disks. + It was implemented this way because bhyve has no notion of an explicit SATA + controller. However, this doesn't go inline with the internal libvirt model, + it was changed for the bhyve driver to follow the common schema and + have PCI addresses for SATA controllers and SATA addresses for disks. If you're having + issues because of this, it's recommended to edit the domain's XML and remove + <address type='xml'> from the <disk> elements with + <target bus="sata"/> and let libvirt regenerate it properly. + </description> + </change> </section> </release> <release version="v3.0.0" date="2017-01-17"> -- 2.11.0
On Sun, 2017-02-05 at 16:52 +0400, Roman Bogorodskiy wrote: [...]
+ <change> + <summary> + bhyve: change address allocation schema for SATA disks + </summary>
The indentation is all wrong, here and below. Please indent using only spaces and make sure the result matches existing entries; be also mindful of line length.
+ <description> + Previously, the bhyve driver assigned PCI addresses to SATA disks directly + rather than assigning that to a controller and using SATA addresses for disks. + It was implemented this way because bhyve has no notion of an explicit SATA + controller.
Aside: does this mean there is an implicit, default SATA controller? How would that work otherwise?
However, this doesn't go inline with the internal libvirt model,
"However, as this doesn't match libvirt's understanding of disk addresses, [...]" or something along those lines.
+ it was changed for the bhyve driver to follow the common schema and + have PCI addresses for SATA controllers and SATA addresses for disks. If you're having + issues because of this, it's recommended to edit the domain's XML and remove + <address type='xml'> from the <disk> elements with
s/xml/pci/ here, I assume.
+ <target bus="sata"/> and let libvirt regenerate it properly.
s/"/'/g to match the above and what libvirt actually uses ;) -- Andrea Bolognani / Red Hat / Virtualization
Andrea Bolognani wrote:
On Sun, 2017-02-05 at 16:52 +0400, Roman Bogorodskiy wrote: [...]
+ <change> + <summary> + bhyve: change address allocation schema for SATA disks + </summary>
The indentation is all wrong, here and below. Please indent using only spaces and make sure the result matches existing entries; be also mindful of line length.
Oops, need to configure vim for proper indentation for these files. Fixed.
+ <description> + Previously, the bhyve driver assigned PCI addresses to SATA disks directly + rather than assigning that to a controller and using SATA addresses for disks. + It was implemented this way because bhyve has no notion of an explicit SATA + controller.
Aside: does this mean there is an implicit, default SATA controller? How would that work otherwise?
Sort of. I mean that there's no such thing as 'slot:func:controller:controller_id' + 'controller_id:disk' or something like that, it's just disk 'slot:func:ahci-(hd|cd):image_path'.
However, this doesn't go inline with the internal libvirt model,
"However, as this doesn't match libvirt's understanding of disk addresses, [...]" or something along those lines.
Done.
+ it was changed for the bhyve driver to follow the common schema and + have PCI addresses for SATA controllers and SATA addresses for disks. If you're having + issues because of this, it's recommended to edit the domain's XML and remove + <address type='xml'> from the <disk> elements with
s/xml/pci/ here, I assume.
Right, fixed.
+ <target bus="sata"/> and let libvirt regenerate it properly.
s/"/'/g to match the above and what libvirt actually uses ;)
Done.
-- Andrea Bolognani / Red Hat / Virtualization
Roman Bogorodskiy
participants (2)
-
Andrea Bolognani -
Roman Bogorodskiy