External/libvirt
1
0
Fork 0
mirror of https://gitlab.com/libvirt/libvirt.git synced 2024-11-05 12:51:12 +00:00
Code Issues Packages Projects Releases Wiki Activity
d7ae7ce363
libvirt/tests/qemuxml2xmloutdata/hostdev-scsi-autogen-address.xml

121 lines
4.4 KiB
XML
Raw Normal View History

conf: Generate address for scsi host device automatically With unknown good reasons, the attribute "bus" of scsi device address is always set to 0, same for attribute "target". (See virDomainDiskDefAssignAddress). Though we might need to change the algorithm to honor "bus" and "target" too, that's a different issue. The address generator for scsi host device in this patch just follows the unknown good reasons, only considering the "controller" and "unit". It walks through all scsi controllers and their units, to see if the address $controller:0:0:$unit can be used (if not used by any disk or scsi host device yet), if found one, it sits on it, otherwise, it creates a new controller (actually the controller is implicitly created by someone else), and sits on $new_controller:0:0:0 instead.
2013-05-31 10:09:24 +00:00
<domain type='qemu'>
<name>QEMUGuest2</name>
<uuid>c7a5fdbd-edaf-9466-926a-d65c16db1809</uuid>
<memory unit='KiB'>219100</memory>
<currentMemory unit='KiB'>219100</currentMemory>
<vcpu placement='static'>1</vcpu>
<os>
<type arch='i686' machine='pc'>hvm</type>
<boot dev='hd'/>
</os>
<clock offset='utc'/>
<on_poweroff>destroy</on_poweroff>
<on_reboot>restart</on_reboot>
<on_crash>destroy</on_crash>
<devices>
tests: fix name of 32-bit x86 QEMU binary The 32-bit x86 binary is called qemu-system-i386, not qemu-system-i686. This mistake across many test XML files was not noticed because the mistake was also made in testutilsqemu.c when mocking the capabilities. Reviewed-by: Erik Skultety <eskultet@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-11-29 16:33:37 +00:00
<emulator>/usr/bin/qemu-system-i386</emulator>
conf: Generate address for scsi host device automatically With unknown good reasons, the attribute "bus" of scsi device address is always set to 0, same for attribute "target". (See virDomainDiskDefAssignAddress). Though we might need to change the algorithm to honor "bus" and "target" too, that's a different issue. The address generator for scsi host device in this patch just follows the unknown good reasons, only considering the "controller" and "unit". It walks through all scsi controllers and their units, to see if the address $controller:0:0:$unit can be used (if not used by any disk or scsi host device yet), if found one, it sits on it, otherwise, it creates a new controller (actually the controller is implicitly created by someone else), and sits on $new_controller:0:0:0 instead.
2013-05-31 10:09:24 +00:00
<disk type='block' device='disk'>
tests: qemuxml2xml: Remove testing with allowed format detection Nobody should use format detection due to security implications. The result of the change is that 'raw' format will be printed unless specified explicitly. Signed-off-by: Peter Krempa <pkrempa@redhat.com>
2018-03-02 14:43:55 +00:00
<driver name='qemu' type='raw'/>
conf: Generate address for scsi host device automatically With unknown good reasons, the attribute "bus" of scsi device address is always set to 0, same for attribute "target". (See virDomainDiskDefAssignAddress). Though we might need to change the algorithm to honor "bus" and "target" too, that's a different issue. The address generator for scsi host device in this patch just follows the unknown good reasons, only considering the "controller" and "unit". It walks through all scsi controllers and their units, to see if the address $controller:0:0:$unit can be used (if not used by any disk or scsi host device yet), if found one, it sits on it, otherwise, it creates a new controller (actually the controller is implicitly created by someone else), and sits on $new_controller:0:0:0 instead.
2013-05-31 10:09:24 +00:00
<source dev='/dev/HostVG/QEMUGuest2'/>
<target dev='hda' bus='ide'/>
<address type='drive' controller='0' bus='0' target='0' unit='0'/>
</disk>
tests: qemuxml2xml: assign device addresses We use the PreFormat callback for this. Many test cases need to be extended to pass in proper qemuCaps flags so AssignAddresses doesn't throw errors. One test case (pcie-root-port-too-many) is dropped, since it was meant only for checking an error condition in qemuxml2argv, and one we add in AssignAddresses it errors here too. Long term I think AssignAddresses should be handled in qemu's PostParse callback, but that's not entirely straightforward. Handling it here means we can get the test suite churn over with.
2016-01-27 21:03:52 +00:00
<controller type='scsi' index='0' model='virtio-scsi'>
qemu: capabilities: Move setting QEMU_CAPS_DEVICE_VIDEO_PRIMARY to virQEMUCapsInitQMPBasicArch Until we clean up and remove all capabilities which no longer make sense to have separately, we should use virQEMUCapsInitQMPBasicArch to set the defaults as it's used by qemuxml2argvtest when testing with fake capabilities. This allows us to prevent testing dead code paths with the fake capability tests. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Neal Gompa <ngompa13@gmail.com> Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
2021-03-30 15:48:46 +00:00
<address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
tests: qemuxml2xml: assign device addresses We use the PreFormat callback for this. Many test cases need to be extended to pass in proper qemuCaps flags so AssignAddresses doesn't throw errors. One test case (pcie-root-port-too-many) is dropped, since it was meant only for checking an error condition in qemuxml2argv, and one we add in AssignAddresses it errors here too. Long term I think AssignAddresses should be handled in qemu's PostParse callback, but that's not entirely straightforward. Handling it here means we can get the test suite churn over with.
2016-01-27 21:03:52 +00:00
</controller>
<controller type='usb' index='0'>
<address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/>
</controller>
<controller type='ide' index='0'>
<address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/>
</controller>
conf: Generate address for scsi host device automatically With unknown good reasons, the attribute "bus" of scsi device address is always set to 0, same for attribute "target". (See virDomainDiskDefAssignAddress). Though we might need to change the algorithm to honor "bus" and "target" too, that's a different issue. The address generator for scsi host device in this patch just follows the unknown good reasons, only considering the "controller" and "unit". It walks through all scsi controllers and their units, to see if the address $controller:0:0:$unit can be used (if not used by any disk or scsi host device yet), if found one, it sits on it, otherwise, it creates a new controller (actually the controller is implicitly created by someone else), and sits on $new_controller:0:0:0 instead.
2013-05-31 10:09:24 +00:00
<controller type='pci' index='0' model='pci-root'/>
conf: Use existing SCSI hostdev model to create new In virDomainDefMaybeAddHostdevSCSIcontroller when we add a new controller because someone neglected to add one or we're adding one because the existing one is full, we should copy over the model number from the existing controller since whatever we create should at least have the same characteristics as the one we cannot use because it's full. NB: This affects the existing hostdev-scsi-autogen-address test which would add a default ('lsi') SCSI controller for the various scsi_host's that would create a controller for the hostdev.
2017-12-04 20:52:57 +00:00
<controller type='scsi' index='1' model='virtio-scsi'>
qemu: capabilities: Move setting QEMU_CAPS_DEVICE_VIDEO_PRIMARY to virQEMUCapsInitQMPBasicArch Until we clean up and remove all capabilities which no longer make sense to have separately, we should use virQEMUCapsInitQMPBasicArch to set the defaults as it's used by qemuxml2argvtest when testing with fake capabilities. This allows us to prevent testing dead code paths with the fake capability tests. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Neal Gompa <ngompa13@gmail.com> Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
2021-03-30 15:48:46 +00:00
<address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
tests: qemuxml2xml: assign device addresses We use the PreFormat callback for this. Many test cases need to be extended to pass in proper qemuCaps flags so AssignAddresses doesn't throw errors. One test case (pcie-root-port-too-many) is dropped, since it was meant only for checking an error condition in qemuxml2argv, and one we add in AssignAddresses it errors here too. Long term I think AssignAddresses should be handled in qemu's PostParse callback, but that's not entirely straightforward. Handling it here means we can get the test suite churn over with.
2016-01-27 21:03:52 +00:00
</controller>
device: cleanup input device code The current code was a little bit odd. At first we've removed all possible implicit input devices from domain definition to add them later back if there was any graphics device defined while parsing XML description. That's not all, while formating domain definition to XML description we at first ignore any input devices with bus different to USB and VIRTIO and few lines later we add implicit input devices to XML. This seems to me as a lot of code for nothing. This patch may look to be more complicated than original approach, but this is a preferred way to modify/add driver specific stuff only in those drivers and not deal with them in common parsing/formating functions. The update is to add those implicit input devices into config XML to follow the real HW configuration visible by guest OS. There was also inconsistence between our behavior and QEMU's in the way, that in QEMU there is no way how to disable those implicit input devices for x86 architecture and they are available always, even without graphics device. This applies also to XEN hypervisor. VZ driver already does its part by putting correct implicit devices into live XML. Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
2016-01-11 11:40:32 +00:00
<input type='mouse' bus='ps2'/>
<input type='keyboard' bus='ps2'/>
qemu: populate <audio> element with default config Currently the QEMU driver secretly sets the QEMU_AUDIO_DRV env variable - VNC - set to "none", unless passthrough of host env variable is set - SPICE - always set to "spice" - SDL - always passthrough host env - No graphics - set to "none", unless passthrough of host env variable is set The setting of the QEMU_AUDIO_DRV env variable is done in the code which configures graphics. If no <audio> element is present, we now auto-populate <audio> elements to reflect this historical default config. This avoids need to set audio env when processing graphics. Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2021-02-24 14:24:10 +00:00
<audio id='1' type='none'/>
conf: Generate address for scsi host device automatically With unknown good reasons, the attribute "bus" of scsi device address is always set to 0, same for attribute "target". (See virDomainDiskDefAssignAddress). Though we might need to change the algorithm to honor "bus" and "target" too, that's a different issue. The address generator for scsi host device in this patch just follows the unknown good reasons, only considering the "controller" and "unit". It walks through all scsi controllers and their units, to see if the address $controller:0:0:$unit can be used (if not used by any disk or scsi host device yet), if found one, it sits on it, otherwise, it creates a new controller (actually the controller is implicitly created by someone else), and sits on $new_controller:0:0:0 instead.
2013-05-31 10:09:24 +00:00
<hostdev mode='subsystem' type='scsi' managed='yes'>
<source>
<adapter name='scsi_host0'/>
<address bus='0' target='0' unit='0'/>
</source>
<address type='drive' controller='0' bus='0' target='0' unit='0'/>
</hostdev>
<hostdev mode='subsystem' type='scsi' managed='yes'>
<source>
<adapter name='scsi_host1'/>
<address bus='0' target='0' unit='1'/>
</source>
<address type='drive' controller='0' bus='0' target='0' unit='1'/>
</hostdev>
<hostdev mode='subsystem' type='scsi' managed='yes'>
<source>
<adapter name='scsi_host2'/>
<address bus='0' target='0' unit='2'/>
</source>
<address type='drive' controller='0' bus='0' target='0' unit='2'/>
</hostdev>
<hostdev mode='subsystem' type='scsi' managed='yes'>
<source>
<adapter name='scsi_host3'/>
<address bus='0' target='0' unit='3'/>
</source>
<address type='drive' controller='0' bus='0' target='0' unit='3'/>
</hostdev>
<hostdev mode='subsystem' type='scsi' managed='yes'>
<source>
<adapter name='scsi_host4'/>
<address bus='0' target='0' unit='4'/>
</source>
<address type='drive' controller='0' bus='0' target='0' unit='4'/>
</hostdev>
<hostdev mode='subsystem' type='scsi' managed='yes'>
<source>
<adapter name='scsi_host5'/>
<address bus='0' target='0' unit='5'/>
</source>
<address type='drive' controller='0' bus='0' target='0' unit='5'/>
</hostdev>
<hostdev mode='subsystem' type='scsi' managed='yes'>
<source>
<adapter name='scsi_host6'/>
<address bus='0' target='0' unit='6'/>
</source>
<address type='drive' controller='0' bus='0' target='0' unit='6'/>
</hostdev>
<hostdev mode='subsystem' type='scsi' managed='yes'>
<source>
<adapter name='scsi_host7'/>
<address bus='0' target='0' unit='7'/>
</source>
<address type='drive' controller='1' bus='0' target='0' unit='0'/>
</hostdev>
<hostdev mode='subsystem' type='scsi' managed='yes'>
<source>
<adapter name='scsi_host8'/>
<address bus='0' target='0' unit='8'/>
</source>
<address type='drive' controller='1' bus='0' target='0' unit='1'/>
</hostdev>
<hostdev mode='subsystem' type='scsi' managed='yes'>
<source>
<adapter name='scsi_host9'/>
<address bus='0' target='0' unit='9'/>
</source>
<address type='drive' controller='1' bus='0' target='0' unit='5'/>
</hostdev>
<hostdev mode='subsystem' type='scsi' managed='yes'>
<source>
<adapter name='scsi_host10'/>
<address bus='0' target='0' unit='10'/>
</source>
<address type='drive' controller='1' bus='0' target='0' unit='2'/>
</hostdev>
tests: qemuxml2xml: assign device addresses We use the PreFormat callback for this. Many test cases need to be extended to pass in proper qemuCaps flags so AssignAddresses doesn't throw errors. One test case (pcie-root-port-too-many) is dropped, since it was meant only for checking an error condition in qemuxml2argv, and one we add in AssignAddresses it errors here too. Long term I think AssignAddresses should be handled in qemu's PostParse callback, but that's not entirely straightforward. Handling it here means we can get the test suite churn over with.
2016-01-27 21:03:52 +00:00
<memballoon model='virtio'>
qemu: capabilities: Move setting QEMU_CAPS_DEVICE_VIDEO_PRIMARY to virQEMUCapsInitQMPBasicArch Until we clean up and remove all capabilities which no longer make sense to have separately, we should use virQEMUCapsInitQMPBasicArch to set the defaults as it's used by qemuxml2argvtest when testing with fake capabilities. This allows us to prevent testing dead code paths with the fake capability tests. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Neal Gompa <ngompa13@gmail.com> Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
2021-03-30 15:48:46 +00:00
<address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
tests: qemuxml2xml: assign device addresses We use the PreFormat callback for this. Many test cases need to be extended to pass in proper qemuCaps flags so AssignAddresses doesn't throw errors. One test case (pcie-root-port-too-many) is dropped, since it was meant only for checking an error condition in qemuxml2argv, and one we add in AssignAddresses it errors here too. Long term I think AssignAddresses should be handled in qemu's PostParse callback, but that's not entirely straightforward. Handling it here means we can get the test suite churn over with.
2016-01-27 21:03:52 +00:00
</memballoon>
conf: Generate address for scsi host device automatically With unknown good reasons, the attribute "bus" of scsi device address is always set to 0, same for attribute "target". (See virDomainDiskDefAssignAddress). Though we might need to change the algorithm to honor "bus" and "target" too, that's a different issue. The address generator for scsi host device in this patch just follows the unknown good reasons, only considering the "controller" and "unit". It walks through all scsi controllers and their units, to see if the address $controller:0:0:$unit can be used (if not used by any disk or scsi host device yet), if found one, it sits on it, otherwise, it creates a new controller (actually the controller is implicitly created by someone else), and sits on $new_controller:0:0:0 instead.
2013-05-31 10:09:24 +00:00
</devices>
</domain>
Reference in New Issue Copy Permalink