openkylin
/
libvirt
mirror of https://gitee.com/openkylin/libvirt.git
9
0
Fork 0
Code Issues Projects Releases Wiki Activity
libvirt/tests/qemuxml2argvdata/disk-source-pool-mode.xml

63 lines
2.2 KiB
XML
Raw Normal View History

conf: Introduce new XML tag "mode" for disk source There are two ways to use a iSCSI LUN as disk source for qemu. * The LUN's path as it shows up on host, e.g. /dev/disk/by-path/ip-$ip:3260-iscsi-$iqn-fc18:iscsi.iscsi0-lun-1 * The libiscsi URI from the storage pool source element host attribute, e.g. iscsi://demo.org:6000/iqn.1992-01.com.example/1 For a "volume" type disk, if the specified "pool" is of iscsi type, we should support to use the LUN in either of above 2 ways. That's why to introduce a new XML tag "mode" for the disk source (libvirt should support iscsi pool with libiscsi, but it's another new feature, which should be done later). The "mode" can be either of "host" or "direct". Use "host" to indicate use of the LUN with the path as it shows up on host. Use "direct" to indicate to use it with the source pool host URI (future patches may support to use network type libvirt storage too, e.g. Ceph)
2013-07-19 01:18:03 +08:00
<domain type='qemu'>
<name>QEMUGuest1</name>
<uuid>c7a5fdbd-edaf-9455-926a-d65c16db1809</uuid>
<memory unit='KiB'>219136</memory>
<currentMemory unit='KiB'>219136</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: unify qemu binary paths for all qemu related tests Our test data used a lot of different qemu binary paths and some of them were based on downstream systems. Note that there is one file where I had to add "accel=kvm" because the qemuargv2xml code parses "/usr/bin/kvm" as virt type="kvm". Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
2017-04-07 00:19:48 +08:00
<emulator>/usr/bin/qemu-system-i686</emulator>
conf: Introduce new XML tag "mode" for disk source There are two ways to use a iSCSI LUN as disk source for qemu. * The LUN's path as it shows up on host, e.g. /dev/disk/by-path/ip-$ip:3260-iscsi-$iqn-fc18:iscsi.iscsi0-lun-1 * The libiscsi URI from the storage pool source element host attribute, e.g. iscsi://demo.org:6000/iqn.1992-01.com.example/1 For a "volume" type disk, if the specified "pool" is of iscsi type, we should support to use the LUN in either of above 2 ways. That's why to introduce a new XML tag "mode" for the disk source (libvirt should support iscsi pool with libiscsi, but it's another new feature, which should be done later). The "mode" can be either of "host" or "direct". Use "host" to indicate use of the LUN with the path as it shows up on host. Use "direct" to indicate to use it with the source pool host URI (future patches may support to use network type libvirt storage too, e.g. Ceph)
2013-07-19 01:18:03 +08:00
<disk type='volume' device='cdrom'>
qemuxml2argv: Add test for disk type='volume' with iSCSI pools Tweak the existing file so that it can be tested for command line corectness.
2013-11-21 18:04:50 +08:00
<source pool='pool-iscsi-auth' volume='unit:0:0:1' mode='host'>
conf: Introduce new XML tag "mode" for disk source There are two ways to use a iSCSI LUN as disk source for qemu. * The LUN's path as it shows up on host, e.g. /dev/disk/by-path/ip-$ip:3260-iscsi-$iqn-fc18:iscsi.iscsi0-lun-1 * The libiscsi URI from the storage pool source element host attribute, e.g. iscsi://demo.org:6000/iqn.1992-01.com.example/1 For a "volume" type disk, if the specified "pool" is of iscsi type, we should support to use the LUN in either of above 2 ways. That's why to introduce a new XML tag "mode" for the disk source (libvirt should support iscsi pool with libiscsi, but it's another new feature, which should be done later). The "mode" can be either of "host" or "direct". Use "host" to indicate use of the LUN with the path as it shows up on host. Use "direct" to indicate to use it with the source pool host URI (future patches may support to use network type libvirt storage too, e.g. Ceph)
2013-07-19 01:18:03 +08:00
<seclabel model='selinux' relabel='yes'>
<label>system_u:system_r:public_content_t:s0</label>
</seclabel>
</source>
<target dev='hda' bus='ide'/>
<readonly/>
<address type='drive' controller='0' bus='0' target='0' unit='1'/>
</disk>
<disk type='volume' device='cdrom'>
qemuxml2argv: Add test for disk type='volume' with iSCSI pools Tweak the existing file so that it can be tested for command line corectness.
2013-11-21 18:04:50 +08:00
<source pool='pool-iscsi' volume='unit:0:0:2' mode='direct'>
conf: Introduce new XML tag "mode" for disk source There are two ways to use a iSCSI LUN as disk source for qemu. * The LUN's path as it shows up on host, e.g. /dev/disk/by-path/ip-$ip:3260-iscsi-$iqn-fc18:iscsi.iscsi0-lun-1 * The libiscsi URI from the storage pool source element host attribute, e.g. iscsi://demo.org:6000/iqn.1992-01.com.example/1 For a "volume" type disk, if the specified "pool" is of iscsi type, we should support to use the LUN in either of above 2 ways. That's why to introduce a new XML tag "mode" for the disk source (libvirt should support iscsi pool with libiscsi, but it's another new feature, which should be done later). The "mode" can be either of "host" or "direct". Use "host" to indicate use of the LUN with the path as it shows up on host. Use "direct" to indicate to use it with the source pool host URI (future patches may support to use network type libvirt storage too, e.g. Ceph)
2013-07-19 01:18:03 +08:00
<seclabel model='selinux' relabel='yes'>
<label>system_u:system_r:public_content_t:s0</label>
</seclabel>
</source>
disk: Disallow duplicated target 'dev' values https://bugzilla.redhat.com/show_bug.cgi?id=1142631 This patch resolves a situation where the same "<target dev='$name'...>" can be used for multiple disks in the domain. While the $name is "mostly" advisory regarding the expected order that the disk is added to the domain and not guaranteed to map to the device name in the guest OS, it still should be unique enough such that other domblk* type operations can be performed. Without the patch, the domblklist will list the same Target twice: $ virsh domblklist $dom Target Source ------------------------------------------------ sda /var/lib/libvirt/images/file.qcow2 sda /var/lib/libvirt/images/file.img Additionally, getting domblkstat, domblkerror, domblkinfo, and other block* type calls will not be able to reference the second target. Fortunately, hotplug disallows adding a "third" sda value: $ qemu-img create -f raw /var/lib/libvirt/images/file2.img 10M $ virsh attach-disk $dom /var/lib/libvirt/images/file2.img sda error: Failed to attach disk error: operation failed: target sda already exists $ BUT, it since 'sdb' doesn't exist one would get the following on the same hotplug attempt, but changing to use 'sdb' instead of 'sda' $ virsh attach-disk $dom /var/lib/libvirt/images/file2.img sdb error: Failed to attach disk error: internal error: unable to execute QEMU command 'device_add': Duplicate ID 'scsi0-0-1' for device $ Since we cannot fix this issue at parsing time, the best that can be done so as to not "lose" a domain is to make the check prior to starting the guest with the results as follows: $ virsh start $dom error: Failed to start domain $dom error: XML error: target 'sda' duplicated for disk sources '/var/lib/libvirt/images/file.qcow2' and '/var/lib/libvirt/images/file.img' $ Running 'make check' found a few more instances in the tests where this duplicated target dev value was being used. These also exhibited some duplicated 'id=' values (negating the uniqueness argument of aliases) in the corresponding .args file and of course the *xmlout version of a few input XML files.
2015-02-27 01:20:01 +08:00
<target dev='hdb' bus='ide'/>
conf: Introduce new XML tag "mode" for disk source There are two ways to use a iSCSI LUN as disk source for qemu. * The LUN's path as it shows up on host, e.g. /dev/disk/by-path/ip-$ip:3260-iscsi-$iqn-fc18:iscsi.iscsi0-lun-1 * The libiscsi URI from the storage pool source element host attribute, e.g. iscsi://demo.org:6000/iqn.1992-01.com.example/1 For a "volume" type disk, if the specified "pool" is of iscsi type, we should support to use the LUN in either of above 2 ways. That's why to introduce a new XML tag "mode" for the disk source (libvirt should support iscsi pool with libiscsi, but it's another new feature, which should be done later). The "mode" can be either of "host" or "direct". Use "host" to indicate use of the LUN with the path as it shows up on host. Use "direct" to indicate to use it with the source pool host URI (future patches may support to use network type libvirt storage too, e.g. Ceph)
2013-07-19 01:18:03 +08:00
<readonly/>
<address type='drive' controller='0' bus='0' target='0' unit='2'/>
</disk>
<disk type='file' device='disk'>
<source file='/tmp/idedisk.img'/>
<target dev='hdc' bus='ide'/>
<address type='drive' controller='0' bus='0' target='0' unit='3'/>
</disk>
docs: Remove unnecessary <auth> example for iscsi disk type='volume' Alter the example to remove the <auth> from: <disk type='volume' device='disk'> <driver name='qemu' type='raw'/> <source pool='iscsi-pool' volume='unit:0:0:1' mode='host'/> <auth username='myuser'> <secret type='iscsi' usage='libvirtiscsi'/> </auth> <target dev='vdb' bus='virtio'/> </disk> and <disk type='volume' device='disk'> <driver name='qemu' type='raw'/> <source pool='iscsi-pool' volume='unit:0:0:2' mode='direct'/> <auth username='myuser'> <secret type='iscsi' usage='libvirtiscsi'/> </auth> <target dev='vdc' bus='virtio'/> </disk> The reality is, it's not even used. For a <source pool> the authdef from the storage source pool will supercede whatever is in the <disk> definition during virStorageTranslateDiskSourcePool processing. In fact, if the pool doesn't have/need authentication, then the authdef would be removed anyway as the storage pool would be handling things. The "proof" for this is in the adjustment to the test to add an <auth> for a disk. The resulting .args file won't add what normally would be added "myname:encodedpassword@" prior to the hostname in the IQN (e.g. iscsi://myname:encodedpassword@iscsi.example.org:3260/...
2017-09-14 02:22:55 +08:00
<disk type='volume' device='cdrom'>
<auth username='myname'>
<secret type='iscsi' usage='mycluster_myname'/>
</auth>
<source pool='pool-iscsi' volume='unit:0:0:3' mode='direct'>
<seclabel model='selinux' relabel='yes'>
<label>system_u:system_r:public_content_t:s0</label>
</seclabel>
</source>
<target dev='hdd' bus='ide'/>
<readonly/>
<address type='drive' controller='0' bus='0' target='0' unit='4'/>
</disk>
conf: Introduce new XML tag "mode" for disk source There are two ways to use a iSCSI LUN as disk source for qemu. * The LUN's path as it shows up on host, e.g. /dev/disk/by-path/ip-$ip:3260-iscsi-$iqn-fc18:iscsi.iscsi0-lun-1 * The libiscsi URI from the storage pool source element host attribute, e.g. iscsi://demo.org:6000/iqn.1992-01.com.example/1 For a "volume" type disk, if the specified "pool" is of iscsi type, we should support to use the LUN in either of above 2 ways. That's why to introduce a new XML tag "mode" for the disk source (libvirt should support iscsi pool with libiscsi, but it's another new feature, which should be done later). The "mode" can be either of "host" or "direct". Use "host" to indicate use of the LUN with the path as it shows up on host. Use "direct" to indicate to use it with the source pool host URI (future patches may support to use network type libvirt storage too, e.g. Ceph)
2013-07-19 01:18:03 +08:00
<controller type='usb' index='0'/>
<controller type='ide' index='0'/>
<controller type='pci' index='0' model='pci-root'/>
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 19:40:32 +08:00
<input type='mouse' bus='ps2'/>
<input type='keyboard' bus='ps2'/>
conf: Introduce new XML tag "mode" for disk source There are two ways to use a iSCSI LUN as disk source for qemu. * The LUN's path as it shows up on host, e.g. /dev/disk/by-path/ip-$ip:3260-iscsi-$iqn-fc18:iscsi.iscsi0-lun-1 * The libiscsi URI from the storage pool source element host attribute, e.g. iscsi://demo.org:6000/iqn.1992-01.com.example/1 For a "volume" type disk, if the specified "pool" is of iscsi type, we should support to use the LUN in either of above 2 ways. That's why to introduce a new XML tag "mode" for the disk source (libvirt should support iscsi pool with libiscsi, but it's another new feature, which should be done later). The "mode" can be either of "host" or "direct". Use "host" to indicate use of the LUN with the path as it shows up on host. Use "direct" to indicate to use it with the source pool host URI (future patches may support to use network type libvirt storage too, e.g. Ceph)
2013-07-19 01:18:03 +08:00
<memballoon model='virtio'/>
</devices>
</domain>