6:52 a.m.
---
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
11:08 a.m.
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
11:49 a.m.
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
2846
days inactive
2847
days old
2 comments
2 participants
participants (2)
-
Andrea Bolognani -
Roman Bogorodskiy