- 09 12月, 2015 6 次提交
-
-
由 Peter Krempa 提交于
Later on this will also be used to track size of the vcpu data array. Use size_t so that we can utilize the memory allocation helpers.
-
由 Peter Krempa 提交于
-
由 Peter Krempa 提交于
-
由 Peter Krempa 提交于
Finalize the refactor by adding the 'virDomainDefGetVCpusMax' getter and reusing it accross libvirt.
-
由 Peter Krempa 提交于
The new helper will simplify checking whether the domain config contains inactive vCPUs.
-
由 Peter Krempa 提交于
To support further refactors replace all write access to def->maxvcpus with a accessor function.
-
- 30 11月, 2015 3 次提交
-
-
由 Michal Privoznik 提交于
Our domain_conf.* files are big enough. Not only they contain XML parsing code, but they served as a storage of all functions whose name is virDomain prefixed. This is just wrong as it gathers not related functions (and modules) into one big file which is then harder to maintain. Split virDomainObjList module into a separate file called virdomainobjlist.[ch]. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Ján Tomko 提交于
Add xml for the new virtio-input-host-pci device: <input type='passthrough' bus='virtio'> <source evdev='/dev/input/event1234'/> </input> https://bugzilla.redhat.com/show_bug.cgi?id=1231114
-
由 Ján Tomko 提交于
To be used by the family of virtio input devices: <input type='mouse' bus='virtio'/> <input type='tablet' bus='virtio'/> <input type='keyboard' bus='virtio'/> https://bugzilla.redhat.com/show_bug.cgi?id=1231114
-
- 27 11月, 2015 3 次提交
-
-
由 Marc-André Lureau 提交于
qemu 2.5 provides virtio video device. It can be used with -device virtio-vga for primary devices, or -device virtio-gpu for non-vga devices. However, only the primary device (VGA) is supported with this patch. Reference: https://bugzilla.redhat.com/show_bug.cgi?id=1195176Signed-off-by: NMarc-André Lureau <marcandre.lureau@gmail.com> Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Marc-André Lureau 提交于
Allowing to have the extra undefined/default state. Signed-off-by: NMarc-André Lureau <marcandre.lureau@gmail.com> Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Marc-André Lureau 提交于
Following the domain XML naming Signed-off-by: NMarc-André Lureau <marcandre.lureau@gmail.com>
-
- 25 11月, 2015 2 次提交
-
-
由 Dmitry Andreev 提交于
'model' attribute was added to a panic device but only one panic device is allowed. This patch changes panic device presence from 'optional' to 'zeroOrMore'.
-
由 Dmitry Andreev 提交于
Libvirt already has two types of panic devices - pvpanic and pSeries firmware. This patch introduces the 'model' attribute and a new type of panic device. 'isa' model is for ISA pvpanic device. 'pseries' model is a default value for pSeries guests. 'hyperv' model is the new type. It's used for Hyper-V crash. Schema and docs are updated for the new attribute.
-
- 18 11月, 2015 1 次提交
-
-
由 Peter Krempa 提交于
Adjust the config code so that it does not enforce that target memory node is specified. To avoid breakage, adjust the qemu memory hotplug config checker to disallow such config for now.
-
- 10 11月, 2015 1 次提交
-
-
由 Peter Krempa 提交于
Keep const correctness and allow to use this function in cases where @def is const in the caller.
-
- 05 10月, 2015 1 次提交
-
-
由 Peter Krempa 提交于
Rename the function to virDomainDefCheckDuplicateDiskInfo and make it check disk serials too. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1245013
-
- 26 9月, 2015 2 次提交
-
-
由 Shivangi Dhir 提交于
Earlier virtType was of type int. After, introducing the enum VIR_DOMAIN_VIRT_NONE, the type of virtType is modified to virDomainVirtType.
-
由 Shivangi Dhir 提交于
Introduce VIR_DOMAIN_VIRT_NONE to give domaintype the default value of zero. This is specially helpful in constructing better error messages when we don't want to look up the default emulator by virtType. The test data in vircapstest.c is also modified to reflect this change.
-
- 22 9月, 2015 7 次提交
-
-
由 Peter Krempa 提交于
When implementing memory hotplug I've opted to recalculate the initial memory size (contents of the <memory> element) as a sum of the sizes of NUMA nodes when NUMA was enabled. This was based on an assumption that qemu did not allow starting when the NUMA node size total didn't equal to the initial memory size. Unfortunately the check was introduced to qemu just lately. This patch uses the new XML parser flag to decide whether it's safe to update the memory size total from the NUMA cell sizes or not. As an additional improvement we now report an error in case when the size of hotplug memory would exceed the total memory size. The rest of the changes assures that the function is called with correct flags.
-
由 Peter Krempa 提交于
Add 'initial_memory' member to struct virDomainMemtune so that the memory size can be pre-calculated once instead of inferring it always again and again. Separating of the fields will also allow finer granularity of decisions in later patches where it will allow to keep the old initial memory value in cases where we are handling incomming migration from older versions that did not always update the size from NUMA as the code did previously. The change also requires modification of the qemu memory alignment function since at the point where we are modifying the size of NUMA nodes the total size needs to be recalculated too. The refactoring done in this patch also fixes a crash in the hyperv driver that did not properly initialize def->numa and thus virDomainNumaGetMemorySize(def->numa) crashed. In summary this patch should have no functional impact at this point.
-
由 Peter Krempa 提交于
The name of the variable was misleading. Rename it and it's setting accessor before other fixes.
-
由 Peter Krempa 提交于
Add a new parser flag that will mark code paths that parse XML files wich will not be used with existing VM state so that post parse callbacks can possibly do ABI incompatible changes if needed.
-
由 Peter Krempa 提交于
-
由 Peter Krempa 提交于
The flag was used only for formatting the XML and once the parser and formatter flags were split in 0ecd6851 it doesn't make sense any more to have it.
-
由 Peter Krempa 提交于
Add a simple helper so that the code doesn't have to rewrite the same condition multiple times.
-
- 18 9月, 2015 1 次提交
-
-
由 Michal Privoznik 提交于
I always felt like this function is qemu specific rather than libvirt-wide. Other drivers may act differently on virDomainDef change and in fact may require talking to underlying hypervisor even if something else's than disk->src has changed. I know that the function is still incomplete, but lets break that into two commits that are easier to review. This one is pure code movement. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
- 02 9月, 2015 1 次提交
-
-
由 Jonathan Toppins 提交于
Adds a new interface type using UDP sockets, this seems only applicable to QEMU but have edited tree-wide to support the new interface type. The interface type required the addition of a "localaddr" (local address), this then maps into the following xml and qemu call. <interface type='udp'> <mac address='52:54:00:5c:67:56'/> <source address='127.0.0.1' port='11112'> <local address='127.0.0.1' port='22222'/> </source> <model type='virtio'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/> </interface> QEMU call: -net socket,udp=127.0.0.1:11112,localaddr=127.0.0.1:22222 Notice the xml "local" entry becomes the "localaddr" for the qemu call. reference: http://lists.gnu.org/archive/html/qemu-devel/2011-11/msg00629.htmlSigned-off-by: NJonathan Toppins <jtoppins@cumulusnetworks.com> Signed-off-by: NJán Tomko <jtomko@redhat.com>
-
- 14 8月, 2015 1 次提交
-
-
由 Tomas Meszaros 提交于
We just need to update the entry in the second hash table. Since commit 8728a565 we have two hash tables for the domain list so that we can do O(1) lookup regardless of looking up by UUID or name. Since with renaming a domain UUID does not change, we only need to update the second hash table, where domains are referenced by their name. We will call both functions from the qemuDomainRename(). Signed-off-by: NTomas Meszaros <exo@tty.sk>
-
- 13 8月, 2015 2 次提交
-
-
由 Martin Kletzander 提交于
This needs a reorder of XML option definitions. It might come in handy one day. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 John Ferlan 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1210587 (completed) When generating the default drive address for a SCSI <disk> device, check the generated address to ensure it doesn't conflict with a SCSI <hostdev> address. The <disk> address generation algorithm uses the <target> "dev" name in order to determine which controller and unit in order to place the device. Since a SCSI <hostdev> device doesn't require a target device name, its placement on the guest SCSI address "could" conflict. For instance, if a SCSI <hostdev> exists at controller=0 unit=0 and an attempt to hotplug 'sda' into the guest made, there would be a conflict if the <hostdev> is already using /dev/sda.
-
- 10 8月, 2015 6 次提交
-
-
由 Martin Kletzander 提交于
This will be used with a virtio-scsi controller later on. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Laine Stump 提交于
This controller can be connected only to a port on a pcie-switch-upstream-port. It provides a single hotpluggable port that will accept any PCI or PCIe device, as well as any device requiring a pcie-*-port (the only current example of such a device is the pcie-switch-upstream-port).
-
由 Laine Stump 提交于
This controller can be connected only to a pcie-root-port or a pcie-switch-downstream-port (which will be added in a later patch), which is the reason for the new connect type VIR_PCI_CONNECT_TYPE_PCIE_PORT. A pcie-switch-upstream-port provides 32 ports (slot=0 to slot=31) on the downstream side, which can only have pci controllers of model "pcie-switch-downstream-port" plugged into them, which is the reason for the other new connect type VIR_PCI_CONNECT_TYPE_PCIE_SWITCH.
-
由 Laine Stump 提交于
This controller can be connected (at domain startup time only - not hotpluggable) only to a port on the pcie root complex ("pcie-root" in libvirt config), hence the new connect type VIR_PCI_CONNECT_TYPE_PCIE_ROOT. It provides a hotpluggable port that will accept any PCI or PCIe device. New attributes must be added to the controller <target> subelement for this - chassis and port are guest-visible option values that will be set by libvirt with values derived from the controller's index and pci address information.
-
由 Laine Stump 提交于
There are some configuration options to some types of pci controllers that are currently automatically derived from other parts of the controller's configuration. For example, in qemu a pci-bridge controller has an option that is called "chassis_nr"; up until now libvirt has always set chassis_nr to the index of the pci-bridge. So this: <controller type='pci' model='pci-bridge' index='2'/> will always result in: -device pci-bridge,chassis_nr=2,... on the qemu commandline. In the future we may decide there is a better way to derive that option, but even in that case we will need for existing domains to retain the same chassis_nr they were using in the past - that is something that is visible to the guest so it is part of the guest ABI and changing it would lead to problems for migrating guests (or just guests with very picky OSes). The <target> subelement has been added as a place to put the new "chassisNr" attribute that will be filled in by libvirt when it auto-generates the chassisNr; it will be saved in the config, then reused any time the domain is started: <controller type='pci' model='pci-bridge' index='2'> <model type='pci-bridge'/> <target chassisNr='2'/> </controller> The one oddity of all this is that if the controller configuration is changed (for example to change the index or the pci address where the controller is plugged in), the items in <target> will *not* be re-generated, which might lead to conflict. I can't really see any way around this, but fortunately if there is a material conflict qemu will let us know and we will pass that on to the user.
-
由 Laine Stump 提交于
This new subelement is used in PCI controllers: the toplevel *attribute* "model" of a controller denotes what kind of PCI controller is being described, e.g. a "dmi-to-pci-bridge", "pci-bridge", or "pci-root". But in the future there will be different implementations of some of those types of PCI controllers, which behave similarly from libvirt's point of view (and so should have the same model), but use a different device in qemu (and present themselves as a different piece of hardware in the guest). In an ideal world we (i.e. "I") would have thought of that back when the pci controllers were added, and used some sort of type/class/model notation (where class was used in the way we are now using model, and model was used for the actual manufacturer's model number of a particular family of PCI controller), but that opportunity is long past, so as an alternative, this patch allows selecting a particular implementation of a pci controller with the "name" attribute of the <model> subelement, e.g.: <controller type='pci' model='dmi-to-pci-bridge' index='1'> <model name='i82801b11-bridge'/> </controller> In this case, "dmi-to-pci-bridge" is the kind of controller (one that has a single PCIe port upstream, and 32 standard PCI ports downstream, which are not hotpluggable), and the qemu device to be used to implement this kind of controller is named "i82801b11-bridge". Implementing the above now will allow us in the future to add a new kind of dmi-to-pci-bridge that doesn't use qemu's i82801b11-bridge device, but instead uses something else (which doesn't yet exist, but qemu people have been discussing it), all without breaking existing configs. (note that for the existing "pci-bridge" type of PCI controller, both the model attribute and <model> name are 'pci-bridge'. This is just a coincidence, since it turns out that in this case the device name in qemu really is a generic 'pci-bridge' rather than being the name of some real-world chip)
-
- 04 8月, 2015 1 次提交
-
-
由 John Ferlan 提交于
Rather than provide a somewhat generic error message when the API returns false, allow the caller to supply a "report = true" option in order to cause virReportError's to describe which of the 3 paths that can cause failure. Some callers don't care about what caused the failure, they just want to have a true/false - for those, calling with report = false should be sufficient.
-
- 20 7月, 2015 1 次提交
-
-
由 Martin Kletzander 提交于
If one calls update-device with information that is not updatable, libvirt reports success even though no data were updated. The example used in the bug linked below uses updating device with <boot order='2'/> which, in my opinion, is a valid thing to request from user's perspective. Mainly since we properly error out if user wants to update such data on a network device for example. And since there are many things that might happen (update-device on disk basically knows just how to change removable media), check for what's changing and moreover, since the function might be usable in other drivers (updating only disk path is a valid possibility) let's abstract it for any two disks. We can't possibly check for everything since for many fields our code does not properly differentiate between default and unspecified values. Even though this could be changed, I don't feel like it's worth the complexity so it's not the aim of this patch. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1007228
-
- 10 7月, 2015 1 次提交
-
-
由 Pavel Hrdina 提交于
There are multiple consumers for the domain condition and we should always wake them all. Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-