libvirt/tests/bhyvexml2argvdata/bhyvexml2argv-bhyveload-bootorder3.args

/usr/sbin/bhyve \
-c 1 \
-m 214 \
-u \
-H \
-P \
-s 0:0,hostbridge \
-s 2:0,ahci,hd:/tmp/freebsd.img,cd:/tmp/cdrom.iso \
-s 3:0,virtio-net,faketapdev,mac=52:54:00:7a:f5:a4 bhyve
bhyve: bhyveload: respect boot dev and boot order Make bhyveload respect boot order as specified by os.boot section of the domain XML or by "boot order" for specific devices. As bhyve does not support a real boot order specification right now, it's just about choosing a single device to boot from. 2015-12-13 03:17:15 +00:00			`/usr/sbin/bhyve \`
			`-c 1 \`
			`-m 214 \`
			`-u \`
			`-H \`
			`-P \`
			`-s 0:0,hostbridge \`
bhyve: fix SATA address allocation As bhyve for a long time didn't have a notion of the explicit SATA controller and created a controller for each drive, the bhyve driver in libvirt acted in a similar way and didn't care about the SATA controllers and assigned PCI addresses to drives directly, as the generated command will look like this anyway: 2:0,ahci-hd,somedisk.img This no longer makes sense because: 1. After commit c07d1c1c4f it's not possible to assign PCI addresses to disks 2. Bhyve now supports multiple disk drives for a controller, so it's going away from 1:1 controller:disk mapping, so the controller object starts to make more sense now So, this patch does the following: - Assign PCI address to SATA controllers (previously we didn't do this) - Assign disk addresses instead of PCI addresses for disks. Now, when building a bhyve command, we take PCI address not from the disk itself but from its controller - Assign addresses at XML parsing time using the assignAddressesCallback. This is done mainly for being able to verify address allocation via xml2xml tests - Adjust existing bhyvexml2{xml,argv} tests to chase the new address allocation This patch is largely based on work of Fabian Freyer. 2017-01-05 12:51:25 +00:00			`-s 2:0,ahci,hd:/tmp/freebsd.img,cd:/tmp/cdrom.iso \`
			`-s 3:0,virtio-net,faketapdev,mac=52:54:00:7a:f5:a4 bhyve`