libvirt/tests/qemuxml2argvdata/qemuxml2argv-channel-guestf...

<domain type='qemu'>
  <name>QEMUGuest1</name>
  <uuid>c7a5fdbd-edaf-9455-926a-d65c16db1809</uuid>
  <memory>219100</memory>
  <currentMemory>219100</currentMemory>
  <vcpu cpuset='1-4,8-20,525'>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>
    <emulator>/usr/bin/qemu</emulator>
    <disk type='block' device='disk'>
      <source dev='/dev/HostVG/QEMUGuest1'/>
      <target dev='hda' bus='ide'/>
      <address type='drive' controller='0' bus='0' unit='0'/>
    </disk>
    <controller type='ide' index='0'/>
    <channel type='pipe'>
      <source path='/tmp/guestfwd'/>
      <target type='guestfwd' address='10.0.2.1' port='4600'/>
    </channel>
    <memballoon model='virtio'/>
  </devices>
</domain>
Forgot test case on previous commit 2009-11-05 22:45:53 +08:00			`<domain type='qemu'>`
			`<name>QEMUGuest1</name>`
			`<uuid>c7a5fdbd-edaf-9455-926a-d65c16db1809</uuid>`
Add VIR_DIV_UP to divide memory or storage request sizes with round up Use it in all places where a memory or storage request size is converted to a larger granularity. This avoids requesting too small memory or storage sizes that could result from the truncation done by a simple division. This extends the round up fix in 6002e0406c338668ea0ecbfeb6c1ef20a8b67efe to the whole codebase. Instead of reporting errors for odd values in the VMX code round them up. Update the QEMU Argv tests accordingly as the original memory size 219200 isn't a even multiple of 1024 and is rounded up to 215 megabyte now. Change it to 219100 and 219136. Use two different values intentionally to make sure that rounding up works. Update virsh.pod accordingly, as rounding down and rejecting are replaced by rounding up. 2011-01-29 05:03:24 +08:00			`<memory>219100</memory>`
			`<currentMemory>219100</currentMemory>`
Forgot test case on previous commit 2009-11-05 22:45:53 +08:00			`<vcpu cpuset='1-4,8-20,525'>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>`
			`<emulator>/usr/bin/qemu</emulator>`
			`<disk type='block' device='disk'>`
			`<source dev='/dev/HostVG/QEMUGuest1'/>`
			`<target dev='hda' bus='ide'/>`
Set default disk controller/bus/unit props When parsing the <disk> element specification, if no <address> is provided for the disk, then automatically assign one based on the <target dev='sdXX'/> device name. This provides for backwards compatability with existing applications using libvirt, while also allowing new apps to have complete fine grained control. * src/conf/domain_conf.h, src/conf/domain_conf.c, src/libvirt_private.syms: Add virDomainDiskDefAssignAddress() for assigning a controller/bus/unit address based on disk target * src/qemu/qemu_conf.c: Call virDomainDiskDefAssignAddress() after generating XML from ARGV * tests/qemuxml2argvdata/*.xml: Add in drive address information to all XML files 2009-12-23 00:53:20 +08:00			`<address type='drive' controller='0' bus='0' unit='0'/>`
Forgot test case on previous commit 2009-11-05 22:45:53 +08:00			`</disk>`
Auto-add disk controllers based on defined disks Existing applications using libvirt are not aware of the disk controller concept. Thus, after parsing the <disk> definitions in the XML, it is neccessary to create <controller> elements to satisfy all requested disks, as per their defined drive addresses * src/conf/domain_conf.c, src/conf/domain_conf.h, src/libvirt_private.syms: Add virDomainDefAddDiskControllers() method for populating disk controllers, and call it after parsing disk definitions. * src/qemu/qemu_conf.c: Call virDomainDefAddDiskControllers() when doing ARGV -> XML conversion * tests/qemuxml2argvdata/qemuxml2argv*.xml: Add disk controller data to all data files which don't have it already 2010-01-05 21:31:20 +08:00			`<controller type='ide' index='0'/>`
Forgot test case on previous commit 2009-11-05 22:45:53 +08:00			`<channel type='pipe'>`
			`<source path='/tmp/guestfwd'/>`
			`<target type='guestfwd' address='10.0.2.1' port='4600'/>`
			`</channel>`
Explicitly represent balloon device in XML and handle PCI address To allow compatibility with older QEMU PCI device slot assignment it is necessary to explicitly track the balloon device in the XML. This introduces a new device <memballoon model='virtio\|xen'/> It can also have a PCI address, auto-assigned if necessary. The memballoon will be automatically added to all Xen and QEMU guests by default. * docs/schemas/domain.rng: Add <memballoon> element * src/conf/domain_conf.c, src/conf/domain_conf.h: parsing and formatting for memballoon device. Always add a memory balloon device to Xen/QEMU if none exists in XML * src/libvirt_private.syms: Export memballoon model APIs * src/qemu/qemu_conf.c, src/qemu/qemu_conf.h: Honour the PCI device address in memory balloon device * tests/*: Update to test new functionality 2010-07-15 21:02:42 +08:00			`<memballoon model='virtio'/>`
Forgot test case on previous commit 2009-11-05 22:45:53 +08:00			`</devices>`
			`</domain>`