Re: libvirt-devaddr: a new library for device address assignment
On Fri, Mar 13, 2020 at 12:47 PM Daniel P. Berrangé wrote: > > On Fri, Mar 13, 2020 at 11:23:44AM +0200, Dan Kenigsberg wrote: > > On Wed, 4 Mar 2020, 14:51 Daniel P. Berrangé, wrote: > > > > > > We've been doing alot of refactoring of code in recent times, and also > > > have plans for significant infrastructure changes. We still need to > > > spend time delivering interesting features to users / applications. > > > This mail is to introduce an idea for a solution to an specific > > > area applications have had long term pain with libvirt's current > > > "mechanism, not policy" approach - device addressing. This is a way > > > for us to show brand new ideas & approaches for what the libvirt > > > project can deliver in terms of management APIs. > > > > > > To set expectations straight: I have written no code for this yet, > > > merely identified the gap & conceptual solution. > > > > > > > > > The device addressing problem > > > = > > > > > > One of the key jobs libvirt does when processing a new domain XML > > > configuration is to assign addresses to all devices that are present. > > > This involves adding various device controllers (PCI bridges, PCI root > > > ports, IDE/SCSI buses, USB controllers, etc) if they are not already > > > present, and then assigning PCI, USB, IDE, SCSI, etc, addresses to each > > > device so they are associated with controllers. When libvirt spawns a > > > QEMU guest, it will pass full address information to QEMU. > > > > > > Libvirt, as a general rule, aims to avoid defining and implementing > > > policy around expansion of guest configuration / defaults, however, it > > > is inescapable in the case of device addressing due to the need to > > > guarantee a stable hardware ABI to make live migration and save/restore > > > to disk work. The policy that libvirt has implemented for device > > > addressing is, as much as possible, the same as the addressing scheme > > > QEMU would apply itself. > > > > > > While libvirt succeeds in its goal of providing a stable hardware API, > > > the addressing scheme used is not well suited to all deployment > > > scenarios of QEMU. This is an inevitable result of having a specific > > > assignment policy implemented in libvirt which has to trade off mutually > > > incompatible use cases/goals. > > > > > > When the libvirt addressing policy is not been sufficient, management > > > applications are forced to take on address assignment themselves, > > > which is a massive non-trivial job with many subtle problems to > > > consider. > > > > > > Places where libvirt's addressing is insufficient for PCI include > > > > > > * Setting up multiple guest NUMA nodes and associating devices to > > >specific nodes > > > * Pre-emptive creation of extra PCIe root ports, to allow for later > > >device hotplug on PCIe topologies > > > * Determining whether to place a device on a PCI or PCIe bridge > > > * Controlling whether a device is placed into a hotpluggable slot > > > * Controlling whether a PCIe root port supports hotplug or not > > > * Determining whether to places all devices on distinct slots or > > >buses, vs grouping them all into functions on the same slot > > > * Ability to expand the device addressing without being on the > > >hypervisor host > > > > (I don't understand the last bullet point) > > I'm not sure if this is still the case, but at some point in time > there was a desire from KubeVirt to be able to expand the users' > configuration when loaded in KubeVirt, filling in various defaults > for devices. This would run when the end user YAML/JSON config > was first posted to the k8s API for storage, some arbitrary amount > of time later the config gets chosen to run on a virtualization > host at which point it is turned into libvirt domain XML. Ah, I did not hear about this before, but I see why something like this would be useful even without libvirt-devaddr. Having something like virDomainDryRunXML() would have eliminated old race conditions we had in oVirt. > > > > Libvirt wishes to avoid implementing many different address assignment > > > policies. It also wishes to keep the domain XML as a representation > > > of the virtual hardware, not add a bunch of properties to it which > > > merely serve as tunable input parameters for device addres
Re: libvirt-devaddr: a new library for device address assignment
On Wed, 4 Mar 2020, 14:51 Daniel P. Berrangé, wrote: > > We've been doing alot of refactoring of code in recent times, and also > have plans for significant infrastructure changes. We still need to > spend time delivering interesting features to users / applications. > This mail is to introduce an idea for a solution to an specific > area applications have had long term pain with libvirt's current > "mechanism, not policy" approach - device addressing. This is a way > for us to show brand new ideas & approaches for what the libvirt > project can deliver in terms of management APIs. > > To set expectations straight: I have written no code for this yet, > merely identified the gap & conceptual solution. > > > The device addressing problem > = > > One of the key jobs libvirt does when processing a new domain XML > configuration is to assign addresses to all devices that are present. > This involves adding various device controllers (PCI bridges, PCI root > ports, IDE/SCSI buses, USB controllers, etc) if they are not already > present, and then assigning PCI, USB, IDE, SCSI, etc, addresses to each > device so they are associated with controllers. When libvirt spawns a > QEMU guest, it will pass full address information to QEMU. > > Libvirt, as a general rule, aims to avoid defining and implementing > policy around expansion of guest configuration / defaults, however, it > is inescapable in the case of device addressing due to the need to > guarantee a stable hardware ABI to make live migration and save/restore > to disk work. The policy that libvirt has implemented for device > addressing is, as much as possible, the same as the addressing scheme > QEMU would apply itself. > > While libvirt succeeds in its goal of providing a stable hardware API, > the addressing scheme used is not well suited to all deployment > scenarios of QEMU. This is an inevitable result of having a specific > assignment policy implemented in libvirt which has to trade off mutually > incompatible use cases/goals. > > When the libvirt addressing policy is not been sufficient, management > applications are forced to take on address assignment themselves, > which is a massive non-trivial job with many subtle problems to > consider. > > Places where libvirt's addressing is insufficient for PCI include > > * Setting up multiple guest NUMA nodes and associating devices to >specific nodes > * Pre-emptive creation of extra PCIe root ports, to allow for later >device hotplug on PCIe topologies > * Determining whether to place a device on a PCI or PCIe bridge > * Controlling whether a device is placed into a hotpluggable slot > * Controlling whether a PCIe root port supports hotplug or not > * Determining whether to places all devices on distinct slots or >buses, vs grouping them all into functions on the same slot > * Ability to expand the device addressing without being on the >hypervisor host (I don't understand the last bullet point) > > Libvirt wishes to avoid implementing many different address assignment > policies. It also wishes to keep the domain XML as a representation > of the virtual hardware, not add a bunch of properties to it which > merely serve as tunable input parameters for device addressing > algorithms. > > There is thus a dilemma here. Management applications increasingly > need fine grained control over device addressing, while libvirt > doesn't want to expose fine grained policy controls via the XML. > > > The new libvirt-devaddr API > === > > The way out of this is to define a brand new virt management API > which tackles this specific problem in a way that addresses all the > problems mgmt apps have with device addressing and explicitly > provides a variety of policy impls with tunable behaviour. > > By "new API", I actually mean an entirely new library, completely > distinct from libvirt.so, or anything else we've delivered so > far. The closest we've come to delivering something at this kind > of conceptual level, would be the abortive attempt we made with > "libvirt-builder" to deliver a policy-driven API instead of mechanism > based. This proposal is still quite different from that attempt. > > At a high level > > * The new API is "libvirt-devaddr" - short for "libvirt device addressing" > > * As input it will take > >1. The guest CPU architecture and machine type >2. A list of global tunables specifying desired behaviour of the > address assignment policy >3. A minimal list of devices needed in the virtual machine, with > optional addresses and optional per-device tunables to override > the global tunables > > * As output it will emit > >1. fully expanded list of devices needed in the virtual machine, > with addressing information sufficient to ensure stable hardware ABI > > Initially the API would implement something that behaves the same > way as libvirt's current address assignment API. > > Th
Re: [libvirt PATCH v2 0/6] element (was: virtio failover / vfio auto-plug-on-migrate)
On Fri, 24 Jan 2020, 17:54 Laine Stump, wrote: > V1: https://www.redhat.com/archives/libvir-list/2020-January/msg00813.html > > This all used different names in V1 - in that incarnation the > configuration was done using "failover" and "backupAlias" attributes > added to the subelement of . But the resulting > code was cumbersome and had little bits scattered all over the place > due to needing it in both hostdev and interface parsing/formatting. > > In his review of V1, danpb suggesting just adding a new subelement for > this configuration to free ourselves from the constraints of > parsing/formatting. This ended up dramatically simplifying the code > (hence the lack of V1's refactoring patches in V2, and a decrease in > patch count from 12 to 6). > > During further discussion in email and on IRC, we decided that naming > the element was too limiting, as it implied the behavior of > what is, to libvirt, just two network devices that should be > teamed/bonded together - it's completely up to the hypervisor and > guest what is done with this information. In light of that, we decided > to name the new subelement , and to specify the two > interfaces as "persistent" (an interface that will always remain > plugged in) and "transient" (an interface that may be periodically > unplugged (during migration, in the case of QEMU). So the virtio > device will have > > > > and the hostdev device will have > > > > (note that the persistent interface must have ) > > Given this config, libvirt will add "failover=on" to the device > commandline arg for the virtio device, and > "failover_pair_id=ua-myvirtio" to the arg for the hostdev device (and > when a migration is requested, it will notice if there is a hostdev > that has set, and will allow the migration > in this case, but still disallow migrations of domains with normal > hostdevs). > > In response to these extra commandline options, QEMU will set some > extra capabilities in the virtio device PCI capabilities data, and > will also automatically unplug/re-plug the hostdev device before and > after migration. > > In the guest, the virtio-net driver will notice the extra PCI > capabilities and use this as a clue that it should search for another > device with matching MAC address (NB: the guest driver requires the > two devices to have matching MAC addresses) to join into a bond with > the virtio-net device. I like the abstraction. As I wrote earlier, as a virt-manager user I'd like to specify that two interfaces are teamed; I would not care to copy the mac address of one onto the other. I prefer that libvirt hides this virtio awkwardness by passing the "persistent" mac address to both qemu nics. Would libvirt do this service to its multiple clients? This bond is hard-wired to always prefer the > hostdev device whenever it is present, and use the virtio device as > backup when the hostdev is unplugged. > > > > As mentioned in a followup to the V1 cover letter, there is a > regression in QEMU 4.2.0 that causes QEMU to segv when a hostdev is > unplugged. That bug is fixed with this upstream QEMU patch: > > > https://git.qemu.org/?p=qemu.git;a=commitdiff;h=0446f8121723b134ca1d1ed0b73e96d4a0a8689d;hp=48008198270e3ebcc9394401d676c54ed5ac139c > > Be sure to use a qemu build with this patch applied, or you may not > even be able to start the guest! Also we've found that the > DEVICE_DELETED event is never sent to libvirt when one of these > hostdevs is manually unplugged, meaning that libvirt keeps the device > marked as > "in-use", and it therefore cannot be re-plugged to the guest until > after a complete guest "power cycle". AFAIK there isn't yet a fix for > that bug, so don't expect manual unplug of the device to work. > > Laine Stump (6): > qemu: add capabilities flag for failover feature > conf: parse/format subelement of > qemu: support interface functionality > qemu: allow migration with assigned PCI hostdev if is set > qemu: add wait-unplug to qemu migration status enum > docs: document subelement > > docs/formatdomain.html.in | 100 ++ > docs/news.xml | 28 + > docs/schemas/domaincommon.rng | 19 > src/conf/domain_conf.c| 45 > src/conf/domain_conf.h| 14 +++ > src/qemu/qemu_capabilities.c | 4 + > src/qemu/qemu_capabilities.h | 3 + > src/qemu/qemu_command.c | 9 ++ > src/qemu/qemu_domain.c| 36 ++- > src/qemu/qemu_migration.c | 53 +- > src/qemu/qemu_monitor.c | 1 + > src/qemu/qemu_monitor.h | 1 + > src/qemu/qemu_monitor_json.c | 1 + > .../caps_4.2.0.aarch64.xml| 1 + > .../caps_4.2.0.x86_64.xml | 1 + > .../net-virtio-teaming-network.xml
Re: [libvirt PATCH 12/12] conf/qemu: new attribute "useBackupMAC"
On Tue, Jan 21, 2020 at 4:47 PM Daniel P. Berrangé wrote: > > On Tue, Jan 21, 2020 at 12:46:38PM +0200, Dan Kenigsberg wrote: > > On Mon, Jan 20, 2020 at 8:33 PM Daniel P. Berrangé > > wrote: > > > > > > On Sun, Jan 19, 2020 at 10:24:19PM -0500, Laine Stump wrote: > > > > Current virtio-net drivers that support the failover feature match up > > > > the virtio backup device with its corresponding hostdev device by > > > > looking for an interface with a matching MAC address. Since libvirt > > > > will assign a different random MAC address to each interface that > > > > isn't given an explicit MAC address, this means that the configuration > > > > for any failover pairs must include explicit matching MAC addresses. > > > > > > > > To make life easier, we could have libvirt populate the XML config > > > > with the same auto-generated MAC address for both interfaces when it > > > > detects a failover pair that have no MAC addresses provided (a > > > > failover pair can be detected by matching of the > > > > virtio interface with of the hostdev > > > > interface), but then we would be stuck with that behavior even if the > > > > virtio guest driver later eliminated the requirement that mac > > > > addresses match. > > > > > > > > Additionally, some management software uses the MAC address as the > > > > primary index for its list of network devices, and can't properly deal > > > > with two interfaces having the same MAC address (oVirt). Even > > > > libvirt's own virsh utility uses MAC address (combined with interface > > > > type) to uniquely identify interfaces for the virsh detach-interface > > > > command (in this case, fortunately the runtime interface type is used, > > > > so one of the interfaces will always be of type='hostdev' and the > > > > other type='something-else", so it doesn't currently cause any problem). > > > > > > > > In order to remove the necessity of explicitly setting interface MAC > > > > addresses, as well as permit the two interfaces of a failover pair to > > > > each have a unique index while still fulfilling the current guest > > > > driver requirement that the MAC addresses matchin the guest, this > > > > patch adds a new attribute "useBackupMAC" that is set on the hostdev > > > > interface of the pair. When useBackupMAC='yes', the setup for the > > > > hostdev interface will find the virtio failover interface (using > > > > backupAlias) and use that interface's MAC address to initialize the > > > > MAC address of the hostdev interface; the MAC address in the hostdev > > > > interface config remains unchanged, it just isnt used for device > > > > initialization. > > > > > > > > I made this patch to followup on > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1693587#c12 (where I > > > > suggested this attribute as a possible remedy to oVirt's requirement > > > > that each network device have a unique MAC address). > > > > > > > > Truthfully, I'm not convinced that I want it though, as it seems > > > > "a bit" hackish. In particular, I've thought for a long time that the > > > > "hostdev manager" code in util/virhostdev.c should really live in the > > > > node device driver and be called from the hypervisors via a public API > > > > (so that there is one central place on the host that maintains the > > > > list of in-use PCI devices and their status), but this patch adds an > > > > obstacle to that goal by adding a virDomainDefPtr to more of the APIs in > > > > that library - if this was turned into a public API, then entire > > > > virDomainDef would need to be serialized and sent in the API call, > > > > then parsed at the other end - yuck :-/. NB: there are already > > > > functions in virhostdev.h that take a virDomainDefPtr, so maybe I'm > > > > being too sensitive. > > > > > > > > On the upside, it solves a problem, and default bevahior is unchanged. > > > > > > I don't believe it does solve a real problem. > > > > > > If a mgmt app is capable of setting useBackupMAC=yes when writing the > > > XML doc, then I don't see why it cannot just as easily set the matching > > > MAC address when wring the XML doc
Re: [libvirt PATCH 12/12] conf/qemu: new attribute "useBackupMAC"
On Mon, Jan 20, 2020 at 8:33 PM Daniel P. Berrangé wrote: > > On Sun, Jan 19, 2020 at 10:24:19PM -0500, Laine Stump wrote: > > Current virtio-net drivers that support the failover feature match up > > the virtio backup device with its corresponding hostdev device by > > looking for an interface with a matching MAC address. Since libvirt > > will assign a different random MAC address to each interface that > > isn't given an explicit MAC address, this means that the configuration > > for any failover pairs must include explicit matching MAC addresses. > > > > To make life easier, we could have libvirt populate the XML config > > with the same auto-generated MAC address for both interfaces when it > > detects a failover pair that have no MAC addresses provided (a > > failover pair can be detected by matching of the > > virtio interface with of the hostdev > > interface), but then we would be stuck with that behavior even if the > > virtio guest driver later eliminated the requirement that mac > > addresses match. > > > > Additionally, some management software uses the MAC address as the > > primary index for its list of network devices, and can't properly deal > > with two interfaces having the same MAC address (oVirt). Even > > libvirt's own virsh utility uses MAC address (combined with interface > > type) to uniquely identify interfaces for the virsh detach-interface > > command (in this case, fortunately the runtime interface type is used, > > so one of the interfaces will always be of type='hostdev' and the > > other type='something-else", so it doesn't currently cause any problem). > > > > In order to remove the necessity of explicitly setting interface MAC > > addresses, as well as permit the two interfaces of a failover pair to > > each have a unique index while still fulfilling the current guest > > driver requirement that the MAC addresses matchin the guest, this > > patch adds a new attribute "useBackupMAC" that is set on the hostdev > > interface of the pair. When useBackupMAC='yes', the setup for the > > hostdev interface will find the virtio failover interface (using > > backupAlias) and use that interface's MAC address to initialize the > > MAC address of the hostdev interface; the MAC address in the hostdev > > interface config remains unchanged, it just isnt used for device > > initialization. > > > > I made this patch to followup on > > https://bugzilla.redhat.com/show_bug.cgi?id=1693587#c12 (where I > > suggested this attribute as a possible remedy to oVirt's requirement > > that each network device have a unique MAC address). > > > > Truthfully, I'm not convinced that I want it though, as it seems > > "a bit" hackish. In particular, I've thought for a long time that the > > "hostdev manager" code in util/virhostdev.c should really live in the > > node device driver and be called from the hypervisors via a public API > > (so that there is one central place on the host that maintains the > > list of in-use PCI devices and their status), but this patch adds an > > obstacle to that goal by adding a virDomainDefPtr to more of the APIs in > > that library - if this was turned into a public API, then entire > > virDomainDef would need to be serialized and sent in the API call, > > then parsed at the other end - yuck :-/. NB: there are already > > functions in virhostdev.h that take a virDomainDefPtr, so maybe I'm > > being too sensitive. > > > > On the upside, it solves a problem, and default bevahior is unchanged. > > I don't believe it does solve a real problem. > > If a mgmt app is capable of setting useBackupMAC=yes when writing the > XML doc, then I don't see why it cannot just as easily set the matching > MAC address when wring the XML doc. > > It can still treat both NICs as having a different MAC address in its > own internal code. All it has to do is use the matching MAC address > when writing out the XML config it gives to libvirt. > > I know oVirt has a facility for hook scripts that are add-ons which > can arbitrarily munge the XML that VDSM creates. So AFAICT this doesn't > even need to involve changes to VDSM itself. There can be a hook > script which looks for the config indicating a failover pair, and > rewrites the XML to have the matching MAC addr. > > Such a workaround then only needs to exist for as long as the mgmt > app has this problematic limitation without impacting libvirt's > maint. > > So I don't want to take this application specific hack in libvirt. I see why you can see it as a hack that should not exist in libvirt. However I would try to put out my case for it. This feature creates something very similar to an in-guest bond between an sriov interface to a virtio one. Currently, we ask end users to configure the bond, set the sriov interface as the primary interface, and allow mac-spoofing on the virio interface. To me, the purpose of this feature is to remove the need for end-user intervention. The bond device no longer need to be created in the guest, it can
[libvirt] [PATCH] doc: better explanation for virStoragePoolSetAutostart
The former documentation was an unhelpful tautology. The suggested doc mimicks^Wcopies the one of virDomainSetAutostart. Signed-off-by: Dan Kenigsberg --- src/libvirt-storage.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/libvirt-storage.c b/src/libvirt-storage.c index 1879c6bd60..ed305b9b5e 100644 --- a/src/libvirt-storage.c +++ b/src/libvirt-storage.c @@ -1127,7 +1127,8 @@ virStoragePoolGetAutostart(virStoragePoolPtr pool, * @pool: pointer to storage pool * @autostart: new flag setting * - * Sets the autostart flag + * Configure the storage pool to be automatically started + * when the host machine boots. * * Returns 0 on success, -1 on failure */ -- 2.17.1 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] doc: fix documentation of virDomainSet(Get)Metadata
The documentation of the functions should match the argument name in the actual function signature. Signed-off-by: Dan Kenigsberg --- src/libvirt.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/libvirt.c b/src/libvirt.c index 72a9f6d..f01b6dd 100644 --- a/src/libvirt.c +++ b/src/libvirt.c @@ -10109,14 +10109,14 @@ virDomainGetSecurityLabelList(virDomainPtr domain, /** * virDomainSetMetadata: * @domain: a domain object - * @type: type of description, from virDomainMetadataType + * @type: type of metadata, from virDomainMetadataType * @metadata: new metadata text * @key: XML namespace key, or NULL * @uri: XML namespace URI, or NULL * @flags: bitwise-OR of virDomainModificationImpact * * Sets the appropriate domain element given by @type to the - * value of @description. A @type of VIR_DOMAIN_METADATA_DESCRIPTION + * value of @metadata. A @type of VIR_DOMAIN_METADATA_DESCRIPTION * is free-form text; VIR_DOMAIN_METADATA_TITLE is free-form, but no * newlines are permitted, and should be short (although the length is * not enforced). For these two options @key and @uri are irrelevant and @@ -10202,7 +10202,7 @@ virDomainSetMetadata(virDomainPtr domain, /** * virDomainGetMetadata: * @domain: a domain object - * @type: type of description, from virDomainMetadataType + * @type: type of metadata, from virDomainMetadataType * @uri: XML namespace identifier * @flags: bitwise-OR of virDomainModificationImpact * -- 1.9.3 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] network: disallow / for bridged/macvtap networks
On Fri, Jan 24, 2014 at 02:18:27PM +0200, Laine Stump wrote: > https://bugzilla.redhat.com/show_bug.cgi?id=1057321 pointed out that > we weren't honoring the element in libvirt networks using > . In fact, these networks are just a method of > giving a libvirt network name to an existing Linux host bridge on the > system, and even if it were technically possible for us to set > network-wide bandwidth limits for all the taps on a bridge, it's > probably not a polite thing to do since libvirt is just using a bridge > that was created by someone else for other purposes. Since QoS is not something that libvirt applies based on an explicit request by the admin, I am not sure that this is a convincing argument: if the admin does not want something to be done, they would not request libvirt to do it. > So the proper > thing is to just log an error when someone tries to put a > element in that type of network. Would you explain why the QoS cannot be applied to the bridge interface itself? The fact that it would limit in-host traffic too? Would you update the docs, to expose the non-support of QoS on these networks? > > While looking through the network XML documentation and comparing it > to the networkValidate function, I noticed that we also ignore the > presence of a mac address in the config, even though we do nothing > with it in this case either. > > This patch updates networkValidate() (which is called any time a > persistent network is defined, or a transient network created) to log > an error and fail if it finds either a or element > and the network forward mode is anything except 'route'. 'nat', or > nothing. (Yes, neither of those elements is acceptable for any macvtap > mode, nor for a hostdev network). > > NB: This does *not* cause failure to start any existing network that > contains one of those elements, so someone might have erroneously > defined such a network in the past, and that network will continue to > function unmodified. I considered it too disruptive to suddenly break > working configs on the next reboot after a libvirt upgrade. BTW, is there other means to re-use libvirt's handling of tc in order to apply QoS on the physical-facing leg of the forwarded bridge (in case that we end up going that way). Regards, Dan. -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Users] libvirt migration port configuration and virPortAllocator
On Wed, Jan 08, 2014 at 01:26:23AM +0100, Gianluca Cecchi wrote: > Hello, > following the bugzilla here: > https://bugzilla.redhat.com/show_bug.cgi?id=1019053 > > we have > " > This is now fixed by v1.1.3-188-g0196845 and v1.1.3-189-ge3ef20d > " > > Does this mean that f19 that has > libvirt-1.0.5.8-1.fc19.x86_64 > is out? > Any time soon to update it? > I see at > http://libvirt.org/sources/ > files such as > libvirt-1.1.4-1.fc19.x86_64.rpm > since beginning of November... > any particular reason for no packages neither in updates-testing repo? > > Also, Fedora 20 has libvirt-1.1.3.2-1.fc20.x86_64.rpm > Did it receive the patch update? I see nothing particular in its changelog... I suspect that you'd see this bugfix only on libvirt>=1.2, but the best place for such questions is the libvirt mailing list (CCed). Unfortunately, that version is not even on virt-preview http://fedorapeople.org/groups/virt/virt-preview/fedora-19 (but it is on http://fedorapeople.org/groups/virt/virt-preview/fedora-20 !) Dan. -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] docs: add a permalink to html headers
Note to reviewers: this patch is too naive and has devastating effect of
headers that lack a named anchor element. Still, I'd love to hear your
opinion about the idea.
On Sun, Dec 08, 2013 at 02:05:46PM +0000, Dan Kenigsberg wrote:
> Quite often, I need to cite URLs like
> http://libvirt.org/formatnetwork.html#elementQoS
> but it is annoying to copy them from the table of contents or the html
> source.
>
> This patch borrows from the Python documentation in order to make it
> easier to cite headers on libvirt's oneline documentation.
> ---
> docs/libvirt.css | 13 +
> docs/page.xsl| 7 +++
> 2 files changed, 20 insertions(+)
>
> diff --git a/docs/libvirt.css b/docs/libvirt.css
> index b324ac8..1d27873 100644
> --- a/docs/libvirt.css
> +++ b/docs/libvirt.css
> @@ -498,3 +498,16 @@ div.description pre.code {
> padding: 5px 10px 5px 10px;
> margin-left: 2.5em;
> }
> +
> +a.headerlink {
> +text-decoration: none!important;
> +visibility: hidden;
> +}
> +
> +h2:hover > a.headerlink,
> +h3:hover > a.headerlink,
> +h4:hover > a.headerlink,
> +h5:hover > a.headerlink,
> +h6:hover > a.headerlink {
> +visibility: visible;
> +}
> diff --git a/docs/page.xsl b/docs/page.xsl
> index a2da854..107f6e2 100644
> --- a/docs/page.xsl
> +++ b/docs/page.xsl
> @@ -185,4 +185,11 @@
>
> select="exsl:node-set($inchtml)/html:html/html:body/*" mode="content"/>
>
> +
> + mode="content">
> +
> +
> + ¶
> +
> +
>
> --
> 1.8.3.1
>
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] docs: add a permalink to html headers
Quite often, I need to cite URLs like
http://libvirt.org/formatnetwork.html#elementQoS
but it is annoying to copy them from the table of contents or the html
source.
This patch borrows from the Python documentation in order to make it
easier to cite headers on libvirt's oneline documentation.
---
docs/libvirt.css | 13 +
docs/page.xsl| 7 +++
2 files changed, 20 insertions(+)
diff --git a/docs/libvirt.css b/docs/libvirt.css
index b324ac8..1d27873 100644
--- a/docs/libvirt.css
+++ b/docs/libvirt.css
@@ -498,3 +498,16 @@ div.description pre.code {
padding: 5px 10px 5px 10px;
margin-left: 2.5em;
}
+
+a.headerlink {
+text-decoration: none!important;
+visibility: hidden;
+}
+
+h2:hover > a.headerlink,
+h3:hover > a.headerlink,
+h4:hover > a.headerlink,
+h5:hover > a.headerlink,
+h6:hover > a.headerlink {
+visibility: visible;
+}
diff --git a/docs/page.xsl b/docs/page.xsl
index a2da854..107f6e2 100644
--- a/docs/page.xsl
+++ b/docs/page.xsl
@@ -185,4 +185,11 @@
+
+
+
+
+ ¶
+
+
--
1.8.3.1
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Users] Time keeping in Windows VM
On Tue, Nov 19, 2013 at 04:36:24PM +, Martin Goldstone wrote: > Hi all, > > We're currently experiencing an issue in our production oVirt 3.2.2 > environment (on CentOS 6.4) with time keeping on our Windows guests. It > seems to have appeared around the time of the recent DST change. It's taken > us a while to get to the bottom of this as some machines were created in > the wrong timezone, which muddied the waters a bit. > > It appears that when Windows automatically updated time in the VMs, this > new offset from UTC was not stored correctly, and the next time the host > was shutdown and started back up, the clock was set incorrectly. We > eventually managed to get this to be consistently reproducible: Set the > clock an hour ahead; power off VM; power it back on; set the clock an hour > back (ie return it to the original time), power off and power back on; > observe that the clock has now shifted to an hour before the original time. > This can be observed in the vm_dynamic table on the database. > > To be honest, I don't think that this an oVirt problem, as I've done some > limited testing on another host using virt-manager/libvirt. If I edit the > xml to set the clock offset to variable, using UTC as the basis and setting > the adjustment to 3600 (mimicking how it would have been before the DST > change), when I change the time in the VM back by an hour (as Windows would > do automatically at DST change), the xml shows a new offset of -3600, so it > seems when the clock is changed the offset it's putting in the XML is the > offset based on the time from when the VM was started, not the offset from > UTC. I believe that you are seeing "Bug 956741 - When RHEL VMs are powered off/on time is off by as much as 3 hrs when system comes back up". http://libvirt.org/html/libvirt-libvirt.html#virConnectDomainEventRTCChangeCallback says that utcoffset is relative to UTC. If it's not so, it's a bug (either in the doc or in the code) so I'm copying libvir-list. Which libvirt and qemu versions do you have? > > Does anyone have any suggestions? At the moment, the only things I can > think of doing are either a) shutting down each VM and setting their offset > to 0 in the vm_dynamic table before starting the back up again or b) > setting the time forward and back an appropriate amount of time so that the > offset becomes 0, shutting the VM down and powering it back on again. -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [vdsm] Host local_host running without virtualization hardware acceleration
On Tue, Nov 05, 2013 at 09:08:33AM +0100, Sandro Bonazzola wrote:
> Hi,
> I had to reinstall ovirt yesterday and now it seems that it doesn't work
> anymore.
> I'm running nightly on Fedora 18.
> kernel-3.11.4-101.fc18.x86_64
> sanlock-2.8-1.fc18.x86_64
> libvirt-1.1.4-1.fc18.x86_64
> qemu-1.5.1-1.fc18.x86_64
> vdsm-4.13.0-93.gitea8c8f0.fc18.x86_64
> ovirt-engine-3.4.0-0.2.master.20131104192919.git3b65870.fc18.noarch
>
> engine-setup with all-in-one detects hardware virtualization and allow me to
> configure the system.
> (it fails detecting engine health status due probably to recent changes in
> its URL, I'm already looking into it)
>
> Once added localhost to the engine, it has been moved to non operational mode
> saying
> I don't have virtualization hardware acceleration anymore.
>
> I've found that:
>
> # modinfo kvm
> filename: /lib/modules/3.11.4-101.fc18.x86_64/kernel/arch/x86/kvm/kvm.ko
> license:GPL
> author: Qumranet
> depends:
> intree: Y
> vermagic: 3.11.4-101.fc18.x86_64 SMP mod_unload
> parm: min_timer_period_us:uint
> parm: ignore_msrs:bool
> parm: tsc_tolerance_ppm:uint
> parm: allow_unsafe_assigned_interrupts:Enable device assignment on
> platforms without interrupt remapping support. (bool)
>
> # /usr/bin/qemu-kvm
> Could not access KVM kernel module: No such file or directory
> failed to initialize KVM: No such file or directory
>
> looking at strace:
> open("/dev/kvm", O_RDWR|O_CLOEXEC) = -1 ENOENT (No such file or
> directory)
>
> Any clue on what may be happened?
What's your `lsmod | grep kvm` ?
If empty, does `modprobe kvm_intel` trigger tail-telling lines on
/var/log/message?
Dan.
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] the case for volatile nwfilters
On Thu, Oct 31, 2013 at 09:20:16AM +, Daniel P. Berrange wrote: > > > > I believe you *can* update a filter while it is in use. NWFilter will > build the new ruleset, then switch over to it atomically. Thanks, I was not aware that one code re-define an existing nwfilter. Dan. -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] the case for volatile nwfilters
On Wed, Oct 30, 2013 at 10:13:28AM +, Daniel P. Berrange wrote: > On Wed, Oct 30, 2013 at 11:57:16AM +0200, Laine Stump wrote: > > On 10/29/2013 06:33 PM, Dan Kenigsberg wrote: > > > I'd like oVirt to make a more extensive usage of libvirt's nwfilters in > > > order to implement security groups, i.e. which protocol/port/host should > > > be open on an interface. > > > > > > Since oVirt is cetrally-managed by ovirt-engine, filter definitions > > > should be edited there and kept in its database. However, libivrt's > > > domain xml requires to have a locally-defined filter as well: > > > > > > > > > > > > > > > > > > > > > > > > We can leave with it by defining an ad-hoc filter before staring a VM, > > > deleting it after the VM stops, and collecting garbage (due to system > > > crashes) occasionally. > > > > > > It would be nicer if we could instead have just-in-time filter > > > definition such as > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > avoiding nwfilter persistence. Would something like this be beneficial > > > to other libvirt users? Would it be easy to implement within libvirt? > > > > My first thought when I saw the subject line was of adding a transient > > "define and start" API similar to that used for domains and networks, > > but of course nwfilters have no concept of "start" or "destroy", so they > > wouldn't be able to follow the same semantics as transient domains and > > networks anyway. > > > > Most likely Stefan made nwfilters use in domains all be references to > > the actual nwfilters rather than having them contained in order to 1) > > save duplication in the configuration now, and 2) potentially save > > duplication in the kernel iptables rules in the future. I can see the > > convenience, but wonder how much inefficiency it could lead to. > > > > Structurally it makes sense though, and the xml has conveniently named > > the existing element as so that is still available > > - was there some premonition of this being requested in the future? :-) > > > > I recall that Stefan has been extremely busy elsewhere and unable to > > completely follow libvir-list for awhile, so I'm Cc'ing him - Stefan, do > > you have any opinion/wisdom on this? > > As you say, the reason for not specifying directly on the VM > was to allow us more scope for improving the efficiency of filters in > the future, by using shared rules across VMs. Having separate rules > per guest NIC is a really non-scalable way to do network filtering as > we look to the future where having 1000's of guests per host will be > not uncommon. The use of filter parameters was included to make it > easier to have common filters, whose actual matching is parameterized > where needed. This rules out my fallback to creation of a filter per vnic and removal with vm destruction :-( It seems that OpenStack falls into this trap as well, with neutron/agent/linux/iptables_firewall.py's creation of an iptables chain per port. The remaining alternative is to replicate a set of filters over all managed hosts. Maintaining something like that is a mission from hell, particularly since one cannot update a filter while it's used by an active VM. Any idea for a way out of this impass? Dan. -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] the case for volatile nwfilters
I'd like oVirt to make a more extensive usage of libvirt's nwfilters in order to implement security groups, i.e. which protocol/port/host should be open on an interface. Since oVirt is cetrally-managed by ovirt-engine, filter definitions should be edited there and kept in its database. However, libivrt's domain xml requires to have a locally-defined filter as well: We can leave with it by defining an ad-hoc filter before staring a VM, deleting it after the VM stops, and collecting garbage (due to system crashes) occasionally. It would be nicer if we could instead have just-in-time filter definition such as avoiding nwfilter persistence. Would something like this be beneficial to other libvirt users? Would it be easy to implement within libvirt? Regards, Dan. -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Users] vdsmd seg fault
On Fri, Oct 18, 2013 at 11:32:51AM -0700, Jason Brooks wrote: > > On Fri, 2013-10-18 at 14:16 +0300, Dan Kenigsberg wrote: > > On Thu, Oct 17, 2013 at 05:15:48PM -0400, Jason Brooks wrote: > > > > > > > > > - Original Message - > > > > From: "Dan Ferris" > > > > To: "" > > > > Sent: Tuesday, October 15, 2013 9:24:44 AM > > > > Subject: [Users] vdsmd seg fault > > > > > > > > I updated to the latest Fedora 19 on two test servers, and now vdsmd > > > > will not start. > > > > > > > > Systedctl says this: > > > > > > > > dsmd.service - Virtual Desktop Server Manager > > > > Loaded: loaded (/usr/lib/systemd/system/vdsmd.service; enabled) > > > > Active: failed (Result: exit-code) since Mon 2013-10-14 12:31:30 > > > > EDT; 23h ago > > > >Process: 1788 ExecStart=/lib/systemd/systemd-vdsmd start > > > > (code=exited, status=139) > > > > > > > > Oct 14 12:31:30 rs0-ovirt0.rexdb.us python[1862]: DIGEST-MD5 > > > > ask_user_info() > > > > Oct 14 12:31:30 rs0-ovirt0.rexdb.us python[1862]: DIGEST-MD5 client > > > > step 2 > > > > Oct 14 12:31:30 rs0-ovirt0.rexdb.us python[1862]: DIGEST-MD5 > > > > ask_user_info() > > > > Oct 14 12:31:30 rs0-ovirt0.rexdb.us python[1862]: DIGEST-MD5 > > > > make_client_response() > > > > Oct 14 12:31:30 rs0-ovirt0.rexdb.us python[1862]: DIGEST-MD5 client > > > > step 3 > > > > Oct 14 12:31:30 rs0-ovirt0.rexdb.us systemd-vdsmd[1788]: > > > > /lib/systemd/systemd-vdsmd: line 185: 1862 Segmentation fault > > > > "$VDSM_TOOL" nwfilter > > > > Oct 14 12:31:30 rs0-ovirt0.rexdb.us systemd-vdsmd[1788]: vdsm: Failed to > > > > define network filters on libvirt[FAILED] > > > > Oct 14 12:31:30 rs0-ovirt0.rexdb.us systemd[1]: vdsmd.service: control > > > > process exited, code=exited status=139 > > > > Oct 14 12:31:30 rs0-ovirt0.rexdb.us systemd[1]: Failed to start Virtual > > > > Desktop Server Manager. > > > > Oct 14 12:31:30 rs0-ovirt0.rexdb.us systemd[1]: Unit vdsmd.service > > > > entered failed state. > > > > > > > > Has anyone else experienced this? > > > > > > I just hit this on one of my test installs. > > > > > > I did yum downgrade libvirt* and then vdsmd would start > > > > Which was the faulty libvirt? Was there anything interesting at the > > /var/log/libvirtd.log? > > libvirt-1.0.5.6-3.fc19 -- it started fine until I rebooted. SElinux is > permissive on these machines, btw. These machines are nested inside of > my main oVirt install, as well. > > I couldn't see anything in the libvirtd.log that looked different from > the libvirtd.log on a node w/ the downgraded libvirt. Maybe someone on libvir-list can suggest why something like conn.nwfilterLookupByName(self.filterName).undefine() conn.nwfilterDefineXML(self.buildFilterXml() suddenly segfaults when run in a systemd unit context? -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Users] Migration issues with ovirt 3.3
On Thu, Oct 10, 2013 at 08:40:29AM +0200, Jiri Denemark wrote: > On Wed, Oct 09, 2013 at 16:18:25 +0100, Dan Kenigsberg wrote: > > On Wed, Oct 09, 2013 at 04:52:20PM +0200, Gianluca Cecchi wrote: > > > On Wed, Oct 9, 2013 at 3:43 PM, Dan Kenigsberg wrote: > > > > On Wed, Oct 09, 2013 at 02:42:22PM +0200, Gianluca Cecchi wrote: > > > >> On Tue, Oct 8, 2013 at 10:40 AM, Dan Kenigsberg wrote: > > > >> > > > >> > > > > >> >> > > > >> >> But migration still fails > > > >> >> > > > >> > > > > >> > It seems like an unrelated failure. I do not know what's blocking > > > >> > migration traffic. Could you see if libvirtd.log and qemu logs at > > > >> > source > > > >> > and destinaiton have clues? > > > >> > > > > >> > > > >> It seems that on VM.log under qemu of desdt host I have: > > > >> ... > > > >> -incoming tcp:[::]:49153: Failed to bind socket: Address already in use > > > > > > > > Is that port really taken (`ss -ntp` should tell by whom)? > > > > > > yeah ! > > > It seems gluster uses it on both sides > > > > Since libvirt has been using this port range first, would you open a > > bug on gluster to avoid it? > > > > Dan. (prays that Vdsm is not expected to edit libvirt's migration port > > range on installation) > > If it makes you feel better, you can't even do that :-) Unfortunately, > the port range used for migration is hard-coded in libvirt. And since we > don't use port allocator yet (patches are in progress), we don't > automatically avoid ports that are already taken. All this is going to > change, though. Are these patches posted? Is there a libvirt BZ that tracks this issue? Dan. -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Users] Migration issues with ovirt 3.3
On Wed, Oct 09, 2013 at 04:52:20PM +0200, Gianluca Cecchi wrote: > On Wed, Oct 9, 2013 at 3:43 PM, Dan Kenigsberg wrote: > > On Wed, Oct 09, 2013 at 02:42:22PM +0200, Gianluca Cecchi wrote: > >> On Tue, Oct 8, 2013 at 10:40 AM, Dan Kenigsberg wrote: > >> > >> > > >> >> > >> >> But migration still fails > >> >> > >> > > >> > It seems like an unrelated failure. I do not know what's blocking > >> > migration traffic. Could you see if libvirtd.log and qemu logs at source > >> > and destinaiton have clues? > >> > > >> > >> It seems that on VM.log under qemu of desdt host I have: > >> ... > >> -incoming tcp:[::]:49153: Failed to bind socket: Address already in use > > > > Is that port really taken (`ss -ntp` should tell by whom)? > > yeah ! > It seems gluster uses it on both sides Since libvirt has been using this port range first, would you open a bug on gluster to avoid it? Dan. (prays that Vdsm is not expected to edit libvirt's migration port range on installation) -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Users] Migration issues with ovirt 3.3
On Wed, Oct 09, 2013 at 02:42:22PM +0200, Gianluca Cecchi wrote:
> On Tue, Oct 8, 2013 at 10:40 AM, Dan Kenigsberg wrote:
>
> >
> >>
> >> But migration still fails
> >>
> >
> > It seems like an unrelated failure. I do not know what's blocking
> > migration traffic. Could you see if libvirtd.log and qemu logs at source
> > and destinaiton have clues?
> >
>
> It seems that on VM.log under qemu of desdt host I have:
> ...
> -incoming tcp:[::]:49153: Failed to bind socket: Address already in use
Is that port really taken (`ss -ntp` should tell by whom)?
>
>
> See all:
> - In libvirtd.log of source host
> 2013-10-07 23:20:54.471+: 1209: debug :
> qemuMonitorOpenInternal:751 : QEMU_MONITOR_NEW: mon=0x7fc66412e820
> refs=2 fd=30
> 2013-10-07 23:20:54.472+: 1209: warning :
> qemuDomainObjEnterMonitorInternal:1136 : This thread seems to be the
> async job owner; entering monitor without asking for a nested job is
> dangerous
> 2013-10-07 23:20:54.472+: 1209: debug :
> qemuMonitorSetCapabilities:1145 : mon=0x7fc66412e820
> 2013-10-07 23:20:54.472+: 1209: debug : qemuMonitorSend:887 :
> QEMU_MONITOR_SEND_MSG: mon=0x7fc66412e820
> msg={"execute":"qmp_capabilities","id":"libvirt-1"}
> fd=-1
> 2013-10-07 23:20:54.769+: 1199: error : qemuMonitorIORead:505 :
> Unable to read from monitor: Connection reset by peer
> 2013-10-07 23:20:54.769+: 1199: debug : qemuMonitorIO:638 : Error
> on monitor Unable to read from monitor: Connection reset by peer
> 2013-10-07 23:20:54.769+: 1199: debug : qemuMonitorIO:672 :
> Triggering error callback
> 2013-10-07 23:20:54.769+: 1199: debug :
> qemuProcessHandleMonitorError:351 : Received error on 0x7fc664124fb0
> 'c8again32'
> 2013-10-07 23:20:54.769+: 1209: debug : qemuMonitorSend:899 : Send
> command resulted in error Unable to read from monitor: Connection
> reset by peer
> 2013-10-07 23:20:54.770+: 1199: debug : qemuMonitorIO:638 : Error
> on monitor Unable to read from monitor: Connection reset by peer
> 2013-10-07 23:20:54.770+: 1209: debug : virFileMakePathHelper:1283
> : path=/var/run/libvirt/qemu mode=0777
> 2013-10-07 23:20:54.770+: 1199: debug : qemuMonitorIO:661 :
> Triggering EOF callback
> 2013-10-07 23:20:54.770+: 1199: debug :
> qemuProcessHandleMonitorEOF:294 : Received EOF on 0x7fc664124fb0
> 'c8again32'
> 2013-10-07 23:20:54.770+: 1209: debug : qemuProcessStop:3992 :
> Shutting down VM 'c8again32' pid=18053 flags=0
> 2013-10-07 23:20:54.771+: 1209: error :
> virNWFilterDHCPSnoopEnd:2135 : internal error ifname "vnet0" not in
> key map
> 2013-10-07 23:20:54.782+: 1209: debug : virCommandRunAsync:2251 :
> About to run /bin/sh -c 'IPT="/usr/sbin/iptables"
> $IPT -D libvirt-out -m physdev --physdev-is-bridged --physdev-out
> vnet0 -g FO-vnet0
> $IPT -D libvirt-out -m physdev --physdev-out vnet0 -g FO-vnet0
> $IPT -D libvirt-in -m physdev --physdev-in vnet0 -g FI-vnet0
> $IPT -D libvirt-host-in -m physdev --physdev-in vnet0 -g HI-vnet0
> $IPT -D libvirt-in-post -m physdev --physdev-in vnet0 -j ACCEPT
> $IPT -F FO-vnet0
> $IPT -X FO-vnet0
> $IPT -F FI-vnet0
> $IPT -X FI-vnet0
> $IPT -F HI-vnet0
> $IPT -X HI-vnet0
> IPT="/usr/sbin/ip6tables"
> $IPT -D libvirt-out -m physdev --physdev-is-bridged --physdev-out
> vnet0 -g FO-vnet0
> $IPT -D libvirt-out -m physdev --physdev-out vnet0 -g FO-vnet0
> $IPT -D libvirt-in -m physdev --physdev-in vnet0 -g FI-vnet0
> $IPT -D libvirt-host-in -m physdev --physdev-in vnet0 -g HI-vnet0
> $IPT -D libvirt-in-post -m physdev --physdev-in vnet0 -j ACCEPT
> $IPT -F FO-vnet0
> $IPT -X FO-vnet0
> $IPT -F FI-vnet0
> $IPT -X FI-vnet0
> $IPT -F HI-vnet0
> $IPT -X HI-vnet0
> EBT="/usr/sbin/ebtables"
> $EBT -t nat -D PREROUTING -i vnet0 -j libvirt-I-vnet0
> $EBT -t nat -D POSTROUTING -o vnet0 -j libvirt-O-vnet0
> EBT="/usr/sbin/ebtables"
> collect_chains()
> {
> for tmp2 in $*; do
> for tmp in $($EBT -t nat -L $tmp2 | \
> sed -n "/Bridge chain/,\$ s/.*-j \\([IO]-.*\\)/\\1/p");
> do
> echo $tmp
> collect_chains $tmp
> done
> done
> }
> rm_chains()
> {
> for tmp in $*; do $EBT -t nat -F $tmp; done
> for tmp in $*; do $EBT -t nat -X $tmp; done
> }
> tmp='\''
> '\''
> IFS='\'' '\'''\'' '\''$tmp
> chains="$(collect_chains libvirt-I-vnet0 libvirt-O-vnet0)"
> $EBT -t nat -F libvirt-I-vnet0
> $EBT -t nat -F libvirt-O-vnet0
> rm_chains $chains
&g
Re: [libvirt] [Users] Live Migration failed oVirt 3.3 Nightly
On Sun, Sep 15, 2013 at 09:57:47PM +1000, Andrew Lau wrote: > On Sun, Sep 15, 2013 at 9:34 PM, Dan Kenigsberg wrote: > > > On Sun, Sep 15, 2013 at 08:44:18PM +1000, Andrew Lau wrote: > > > On Sun, Sep 15, 2013 at 8:00 PM, Dan Kenigsberg > > wrote: > > > > > > > On Sun, Sep 15, 2013 at 06:48:41PM +1000, Andrew Lau wrote: > > > > > Hi Dan, > > > > > > > > > > Certainly, I've uploaded them to fedora's paste bin and tried to snip > > > > just > > > > > the relevant details. > > > > > > > > > > Sender (hv01.melb.domain.net): > > > > > http://paste.fedoraproject.org/39660/92339651/ > > > > > > > > This one has > > > > > > > > libvirtError: operation failed: Failed to connect to remote libvirt > > > > URI qemu+tls://hv02.melb.domain.net/system > > > > > > > > which is most often related to firewall issues, and some time to key > > > > mismatch. > > > > > > > > Does > > > > virsh -c qemu+tls://hv02.melb.domain.net/system capabilities > > > > work when run from the command line of hv01? > > > > > > > > Dan. > > > > > Receiver (hv02.melb.domain.net): ` > > > > > http://paste.fedoraproject.org/39661/23406913/ > > > > > > > > > > VM being transfered is ovirt_guest_vm > > > > > > > > > > Thanks, > > > > > Andrew > > > > > > > > > > virsh -c qemu+tls://hv02.melb.domain.net/system > > > 2013-09-15 10:41:10.620+: 23994: info : libvirt version: 0.10.2, > > > package: 18.el6_4.9 (CentOS BuildSystem <http://bugs.centos.org>, > > > 2013-07-02-11:19:29, c6b8.bsys.dev.centos.org) > > > 2013-09-15 10:41:10.620+: 23994: warning : > > > virNetTLSContextCheckCertificate:1102 : Certificate check failed > > > Certificate failed validation: The certificate hasn't got a known issuer. > > > > Would you share your > > > > > > openssl x509 -in > > /etc/pki/vdsm/certs/cacert.pem -text > > > > openssl x509 -in /etc/pki/vdsm/certs/vdsmcert.pem -text > > > > on both hosts? This content may be sensitive, and may not > > provide an answer why libvirt on src cannot contact libvirtd on the > > other host. So before you do that, would you test if > > > > > > vdsClient -s hv02.melb.domain.net getVdsCapabilities > > > > works when run on hv01? It may be that the certificates are fine, but > > libvirt is not configured to use the correct ones. > > > > Dan. > > > > > vdsClient -s hv02.melb.domain.net getVdsCapabilities runs fine > > I did a quick comparison between the files on both hosts, they seem to have > the right details (host names, authority etc.) > cacert.pem matches > > /etc/libvirt/libvirtd.conf > > ca_file="/etc/pki/vdsm/certs/cacert.pem" > cert_file="/etc/pki/vdsm/certs/vdsmcert.pem" > key_file="/etc/pki/vdsm/keys/vdsmkey.pem" Maybe someone on libvir-list could guess why this could be happening? -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Users] Starting VM Error
On Sun, Sep 15, 2013 at 01:59:29PM +0200, Gianluca Cecchi wrote: > On Sun, Sep 15, 2013 at 1:50 PM, Gianluca Cecchi wrote: > > and > > [root@tekkaman ~]# chgrp kvm /var/lib/libvirt/images/testvm.img > [root@tekkaman ~]# ll /var/lib/libvirt/images/testvm.img > -rw-rw. 1 vdsm kvm 197120 Sep 15 12:24 /var/lib/libvirt/images/testvm.img > > [root@tekkaman ~]# virsh undefine testvm2 > Please enter your authentication name: virshuser > Please enter your password: > Domain testvm2 has been undefined > > [root@tekkaman ~]# virsh define /tmp/testvm2.xml > Please enter your authentication name: virshuser > Please enter your password: > Domain testvm2 defined from /tmp/testvm2.xml > > [root@tekkaman ~]# virsh start testvm2 > Please enter your authentication name: virshuser > Please enter your password: > error: Failed to start domain testvm2 > error: internal error Process exited while reading console log output: > char device redirected to /dev/pts/2 > qemu-kvm: -drive > file=/var/lib/libvirt/images//testvm.img,if=none,id=drive-virtio-disk0,format=qcow2: > could not open disk image /var/lib/libvirt/images//testvm.img: > Permission denied Gianluca, due to all the twists of this thread, I no longer recall which libvirt version you are using. Would you remind us? All signs show that it starts up qemu without setting its auxiliary group properly (Assuming that your # groups qemu qemu : qemu kvm is just as mine) I've added libvir-list so the fine folks there could check why qemu cannot read/write files group-owned by kvm. Dan. -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Users] VNC/Spice console connection failure
On Tue, Sep 10, 2013 at 05:31:23PM +, SULLIVAN, Chris (WGK) wrote: > Hi Itamar, > > BZ created: https://bugzilla.redhat.com/show_bug.cgi?id=1006490 > > Thanks, Thanks, but we cannot simply require libvirt > 1.1.0, as it does not ship with F19. We need get a fix backported to F19, so that we can change our VNC password there. (Too bad we've been top-posting here. Now that I'm adding libvir-list I'm going to be cursed.) > > Chris > > -Original Message- > From: Itamar Heim [mailto:ih...@redhat.com] > Sent: Monday, September 09, 2013 8:36 PM > To: SULLIVAN, Chris (WGK) > Cc: us...@ovirt.org; Michal Skrivanek > Subject: Re: [Users] VNC/Spice console connection failure > > On 09/09/2013 12:59 PM, SULLIVAN, Chris (WGK) wrote: > > Hi, > > > > Just to follow up on the below - updating to libvirt 1.1.2-1 from > > ftp://libvirt.org/libvirt/ has appeared to solve the issue. Console > > connections via noVNC work as expected. > > worth opening a bug to require that libvirt version as the minimal version? > > > > > Cheers, > > > > Chris > > > > > > > > PLEASE CONSIDER THE ENVIRONMENT, DON'T PRINT THIS EMAIL UNLESS YOU REALLY > > NEED TO. > > > > This email and its attachments may contain information which is > > confidential and/or legally privileged. If you are not the intended > > recipient of this e-mail please notify the sender immediately by e-mail and > > delete this e-mail and its attachments from your computer and IT systems. > > You must not copy, re-transmit, use or disclose (other than to the sender) > > the existence or contents of this email or its attachments or permit anyone > > else to do so. > > > > - > > > > -Original Message- > > From: SULLIVAN, Chris (WGK) > > Sent: Monday, September 09, 2013 3:48 PM > > To: us...@ovirt.org > > Subject: RE: VNC/Spice console connection failure > > > > Hi, > > > > I am currently unable to connect to the console of a running VM through the > > Ovirt web interface. I get the following error (log extracts below): > > error : qemuDomainChangeGraphics:1873 : internal error cannot > > change listen address setting on vnc graphics > > > > I’m using Fedora 19, ovirt-engine 3.3.0-1, VDSM 4.12.1, qemu 1.4.2 and > > libvirt 1.0.5. I get a similar error when trying to use Spice. > > > > Has anyone come across this problem before, and if so, how to resolve? > > Based on some quick googling the versions of libvirt/qemu available in F19 > > do not allow changes to the listen address for a running VM. Should I > > rollback to a previous version? > > > > Kind regards, > > > > Chris Sullivan > > Senior Pipeline Engineer/Technical Development | J P Kenny > > > > > > ovirt-engine.log > > 2013-09-09 12:22:46,688 INFO > > [org.ovirt.engine.core.bll.SetVmTicketCommand] (ajp--127.0.0.1-8702-4) > > Running command: SetVmTicketCommand internal: false. Entities affected : > > ID: e69df488-ad50-4c8c-9f37-a63463a81702 Type: VM > > 2013-09-09 12:22:46,692 INFO > > [org.ovirt.engine.core.vdsbroker.vdsbroker.SetVmTicketVDSCommand] > > (ajp--127.0.0.1-8702-4) START, SetVmTicketVDSCommand(HostName = r410-02, > > HostId = d5df2e2b-509c-4b1c-902a-976b932d930b, > > vmId=e69df488-ad50-4c8c-9f37-a63463a81702, ticket=igRUBsYsw5ds, > > validTime=120,m userName=admin@internal, > > userId=fdfc627c-d875-11e0-90f0-83df133b58cc), log id: 53359174 > > 2013-09-09 12:22:46,715 ERROR > > [org.ovirt.engine.core.vdsbroker.vdsbroker.SetVmTicketVDSCommand] > > (ajp--127.0.0.1-8702-4) Failed in SetVmTicketVDS method > > 2013-09-09 12:22:46,715 ERROR > > [org.ovirt.engine.core.vdsbroker.vdsbroker.SetVmTicketVDSCommand] > > (ajp--127.0.0.1-8702-4) Error code unexpected and error message > > VDSGenericException: VDSErrorException: Failed to SetVmTicketVDS, error = > > Unexpected exception > > 2013-09-09 12:22:46,716 INFO > > [org.ovirt.engine.core.vdsbroker.vdsbroker.SetVmTicketVDSCommand] > > (ajp--127.0.0.1-8702-4) Command > > org.ovirt.engine.core.vdsbroker.vdsbroker.SetVmTicketVDSCommand return value > > 2013-09-09 12:22:46,716 INFO > > [org.ovirt.engine.core.vdsbroker.vdsbroker.SetVmTicketVDSCommand] > > (ajp--127.0.0.1-8702-4) HostName = r410-02 > > 2013-09-09 12:22:46,717 ERROR > > [org.ovirt.engine.core.vdsbroker.vdsbroker.SetVmTicketVDSCommand] > > (ajp--127.0.0.1-8702-4) Command SetVmTicketVDS execution failed. Exception: > > VDSErrorException: VDSGenericException: VDSErrorException: Failed to > > SetVmTicketVDS, error = Unexpected exception > > 2013-09-09 12:22:46,717 INFO > > [org.ovirt.engine.core.vdsbroker.vdsbroker.SetVmTicketVDSCommand] > > (ajp--127.0.0.1-8702-4) FINISH, SetVmTicketVDSCommand, log id: 53359174 > > 2013-09-09 12:22:46,718 ERROR > > [org.ovirt.engine.core.bll.SetVmTicketCommand] (ajp--127.0.0.1-8702-4) > > Command org.ovirt.engine.core.bll.SetVmTicketCommand throw Vdc Bll > > exception. With error message VdcBLLException: > > org.ovirt.engine.core.vdsbroker.vdsbroker.VDSErro
Re: [libvirt] [PATCH] Configuring systemd to restart libvirt on failure
On Tue, Jul 30, 2013 at 03:32:59PM +0300, Mooli Tayer wrote: > This will create a respawn behaviour in case libvirt > process exits due to nonzero exit code, is terminated > by a signal, an operation times out or the configured > watchdog timeout is triggered. > see http://www.freedesktop.org/software/systemd/man/systemd.service.html > --- > daemon/libvirtd.service.in | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/daemon/libvirtd.service.in b/daemon/libvirtd.service.in > index aa5913b..25979ef 100644 > --- a/daemon/libvirtd.service.in > +++ b/daemon/libvirtd.service.in > @@ -15,6 +15,7 @@ EnvironmentFile=-/etc/sysconfig/libvirtd > ExecStart=@sbindir@/libvirtd $LIBVIRTD_ARGS > ExecReload=/bin/kill -HUP $MAINPID > KillMode=process > +Restart=on-failure > # Override the maximum number of opened files > #LimitNOFILE=2048 FWIW, ack by me. -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Configuring systemd to restart libvirt on abort
On Tue, Jul 30, 2013 at 05:43:16AM -0400, Mooli Tayer wrote: > > - Original Message - > > On Mon, Jul 29, 2013 at 05:36:21PM +0300, Mooli Tayer wrote: > > > From: Mooli Tayer > > > > > > This will create a respawn behaviour in case libvirt > > > process exits due to an uncaught signal not specified > > > as a clean exit status. > > > see http://www.freedesktop.org/software/systemd/man/systemd.service.html > > > --- > > > daemon/libvirtd.service.in | 1 + > > > 1 file changed, 1 insertion(+) > > > > > > diff --git a/daemon/libvirtd.service.in b/daemon/libvirtd.service.in > > > index aa5913b..b3c0849 100644 > > > --- a/daemon/libvirtd.service.in > > > +++ b/daemon/libvirtd.service.in > > > @@ -15,6 +15,7 @@ EnvironmentFile=-/etc/sysconfig/libvirtd > > > ExecStart=@sbindir@/libvirtd $LIBVIRTD_ARGS > > > ExecReload=/bin/kill -HUP $MAINPID > > > KillMode=process > > > +Restart=on-abort > > > # Override the maximum number of opened files > > > #LimitNOFILE=2048 > > > > I'm wondering whether 'on-abort' is the best choice or if > > 'on-failure' or 'always' are better. The systemd.service > > man page says > > > > [quote] > >Takes one of no, on-success, on-failure, > >on-abort, or always. If set to no (the > >default) the service will not be restarted. If > >set to on-success it will be restarted only > >when the service process exits cleanly. In > >this context, a clean exit means an exit code > >of 0, or one of the signals SIGHUP, SIGINT, > >SIGTERM, or SIGPIPE, and additionally, exit > >statuses and signals specified in > >SuccessExitStatus=. If set to on-failure the > >service will be restarted when the process > >exits with an nonzero exit code, is terminated > >by a signal (including on core dump), when an > >operation (such as service reload) times out, > >and when the configured watchdog timeout is > >triggered. If set to on-abort the service will > >be restarted only if the service process exits > >due to an uncaught signal not specified as a > >clean exit status. If set to always the > >service will be restarted regardless whether > >it exited cleanly or not, got terminated > >abnormally by a signal or hit a timeout. > > [/quote] > > > > I tend towards saying 'on-failure' here. > > I agree. we defiantly want restart in the 'on-failure' > cases. Would 'on-failure' mean that libvirtd is to be restarted if it has exited with an error due to wrong configuration? This may spell nasty thrashing of systemd. Dan. -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] qemu64 - not valid cpu with 'Intel Westmere Family'
On Wed, Jul 03, 2013 at 04:51:30PM +0200, Sandro Bonazzola wrote:
> Il 03/07/2013 16:40, Sandro Bonazzola ha scritto:
> > Hi,
> > I'm trying to run latest vdsm master on RHEL-6.4.
> > I've built the rpms against livirt-1.10
> >
> > I'm creating a VM using cpu family = 'Intel Westmere Family'
> >
> >
> > qemu64
> >
> >
> >
> > Thread-40::DEBUG::2013-07-03
> > 15:47:47,150::libvirtconnection::136::vds::(wrapper) Unknown
> > libvirterror: ecode: 1 edom: 31 level: 2 message: internal error Cannot
> > find suitable CPU model for given data
> > Thread-40::DEBUG::2013-07-03
> > 15:47:47,150::vm::2003::vm.Vm::(_startUnderlyingVm)
> > vmId=`9deae1fb-e0c5-4362-8f3c-657f39893b8b`::_ongoingCreations released
> > Thread-40::ERROR::2013-07-03
> > 15:47:47,150::vm::2029::vm.Vm::(_startUnderlyingVm)
> > vmId=`9deae1fb-e0c5-4362-8f3c-657f39893b8b`::The vm start process failed
> > Traceback (most recent call last):
> > File "/usr/share/vdsm/vm.py", line 1989, in _startUnderlyingVm
> > self._run()
> > File "/usr/share/vdsm/vm.py", line 2862, in _run
> > self._connection.createXML(domxml, flags),
> > File "/usr/lib64/python2.6/site-packages/vdsm/libvirtconnection.py",
> > line 112, in wrapper
> > ret = f(*args, **kwargs)
> > File "/usr/lib64/python2.6/site-packages/libvirt.py", line 2848, in
> > createXML
> > if ret is None:raise libvirtError('virDomainCreateXML() failed',
> > conn=self)
> > libvirtError: internal error Cannot find suitable CPU model for given data
> >
> >
> > Is it required a more updated qemu? Is it a vdsm or a livirt bug?
>
>
> It seems that qemu knows qemu64 as cpu
>
> # /usr/libexec/qemu-kvm --cpu ?
And what does `virsh -r capabilities` report?
Is there something interesting in /var/log/libvirtd.log?
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] configuring a disconnected
On Tue, Jul 02, 2013 at 05:32:20PM -0400, Laine Stump wrote: > On 07/02/2013 04:07 PM, Dan Kenigsberg wrote: > > On Mon, Jun 24, 2013 at 11:22:16AM +0100, Daniel P. Berrange wrote: > >> On Sun, Jun 23, 2013 at 03:34:06PM +0300, Dan Kenigsberg wrote: > >>> On Fri, Jun 21, 2013 at 04:31:53AM -0500, Daniel P. Berrange wrote: > >>>> So I'm not inclined to support this disconnected mode. > >>> Disconnected mode exists in actuality. It has valid use cases in the > >>> virtual world as well. I would like to discuss the domxml schema for > >>> representing it, and then, hopefully find the menpower to implement it > >>> outside the core libvirt team. So please, reconsider. > >> The XML schema is easy enough - it is just a new . > >> Ideally we would want some kind of support in QEMU for this, concept > >> so that we don't have to have a hidden dangling tap device > > That would be cool indeed. It would make it possible to > > virDomainUpdateDevice() from a tap-based connectivity to non-tap one. > > > > Until we have something like that in qemu, would it be reasonable to > > implement via a dangling tap? Wouldn't it be fine > > to limit changing type=none to type=network only to bridge-based > > networks? > > Well, that *is* how virDomainUpdateDevice behaves when switching from > one network connection to another - if the source and destination are > both implemented with tap, it works, otherwise it returns > OPERATION_UNSUPPORTED. My question is slightly different: it's about switching from one interface type (=none) to another (=network), not between two networks. I am asking whether it would be fine to implement type=none with tap, given this unsupportedness. Dan. -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] configuring a disconnected
On Mon, Jun 24, 2013 at 11:22:16AM +0100, Daniel P. Berrange wrote: > On Sun, Jun 23, 2013 at 03:34:06PM +0300, Dan Kenigsberg wrote: > > On Fri, Jun 21, 2013 at 04:31:53AM -0500, Daniel P. Berrange wrote: > > > On Thu, Jun 20, 2013 at 02:42:31PM +0300, Dan Kenigsberg wrote: > > > > Hi List, > > > > > > > > Like most of us, I've bought my actual computer with an Ethernet > > > > interface card, that I can connect to a wall jack at will. It's quite > > > > easy to disconnect the Ethernet cable from the wall, as well. > > > > > > > > I would like to expose this behavior to virtual computers, too. Via > > > > libvirt, of course. That's useful, since an admin may need to disconnect > > > > a running VM from a network temporarily, without resorting to > > > > hot-unplugging its nic. > > > > > > In the bug you filed requested this feature, you said that you want > > > this so that you can make oVirt configure bridging behind libvirts > > > back with Quantum. > > > > This is not exact. Bug 878481 - define a disconnected > > was opened with the VM-connected-to-no-bridge in mind. > > > > Since libvirt is lacking this feature, oVirt has introduced an ugly > > hack: a dummy bridge, to which a disconnected VM is moved to. The > > interface fo this VM had to be set with to avoid > > inter-VM communication. > > > > Only then came the Quantum use case. > > Sigh. In the BZ, your justification only mentioned that this is > required for integration with Quantum, never that it was required > separately. Verifying this statement is left as an excercise to the reader of https://bugzilla.redhat.com/show_bug.cgi?id=878481#c0 . > > > > As explained in the bug, this is a really bad way > > > todo this & should not be required - OpenStack Nova demonstrates you > > > can do the right thing wrt Quantum using exisiting libvirt config. > > > > I'm not sure that this is THE right thing. At the momement, both > > quantum's linuxbridge plugin and nova's LinuxBridgeInterfaceDriver have > > an ensure_vlan_bridge() method. > > > > > > I'm no OpenStack expert, but I think that the nicest separation between > > nova's and quantum's domains is the tap device (obviously only for > > networks which use tap devices). Quantum should create the Linux bridge > > and its underlying connectivity (or even worse for ovs with security > > groups...), and Nova should connect a newly-created VM to it. Otherwise, > > Nova would have to reimplement just about any extension that is > > introduced to Quantum. > > While there are many, many ways to configure a physical network, > there are a small, finite number of ways that you can connect a > virtual machine to a physical network. Thus while there can be > many different quantum plugins, Nova only needs to know about a > handful of VM configuration rules. > > > In particular, I worry about the mapping of a network to a physical > > device. Quantum's linuxbridge does it according to a preconfigured > > cfg.CONF.LINUX_BRIDGE.physical_interface_mappings. Does Nova's vif > > driver support something like this? From where does it collect this > > information? > > > > Anyway, would you suggest oVirt to implement its own > > ensure_vlan_bridge()? Or use the vif driver code? Or that of linuxbridge > > quantum plugin? > > I'm not sure you're looking at current codebase. As of Grizzly the > quantum specific VIF plugin (and all other existing VIF plugins) > are deprecated in favour of LibvirtGenericVIFDriver. This defines > (currently) 4 different types of VIF configuration, linux bridge, > openvswitch, 802.qbg and 802.qbh. Each of these VIF types has a > set of metadata associated with it describing the configuration > requirements, which is used to configure the VM interface appropriately. > This clean separation isolates Nova from any knowledge of Quantum, > and vica-verca. I'm looking at the tip of master branch, both in https://github.com/openstack/nova/blob/master/nova/virt/libvirt/vif.py#L342 and https://github.com/openstack/quantum/blob/master/quantum/plugins/linuxbridge/agent/linuxbridge_quantum_agent.py#L679 My spefcific painpoint is that the vif driver calls linux_net.LinuxBridgeInterfaceDriver.ensure_vlan_bridge() with no regards of the configuration of the quantum agent. True, a specific configuration parameter of a specific agent of a quantum plugin is not of the business of Nova. But this suggests that connecting a bridge to an external NIC is not its bus
Re: [libvirt] configuring a disconnected
On Fri, Jun 21, 2013 at 04:31:53AM -0500, Daniel P. Berrange wrote: > On Thu, Jun 20, 2013 at 02:42:31PM +0300, Dan Kenigsberg wrote: > > Hi List, > > > > Like most of us, I've bought my actual computer with an Ethernet > > interface card, that I can connect to a wall jack at will. It's quite > > easy to disconnect the Ethernet cable from the wall, as well. > > > > I would like to expose this behavior to virtual computers, too. Via > > libvirt, of course. That's useful, since an admin may need to disconnect > > a running VM from a network temporarily, without resorting to > > hot-unplugging its nic. > > In the bug you filed requested this feature, you said that you want > this so that you can make oVirt configure bridging behind libvirts > back with Quantum. This is not exact. Bug 878481 - define a disconnected was opened with the VM-connected-to-no-bridge in mind. Since libvirt is lacking this feature, oVirt has introduced an ugly hack: a dummy bridge, to which a disconnected VM is moved to. The interface fo this VM had to be set with to avoid inter-VM communication. Only then came the Quantum use case. > As explained in the bug, this is a really bad way > todo this & should not be required - OpenStack Nova demonstrates you > can do the right thing wrt Quantum using exisiting libvirt config. I'm not sure that this is THE right thing. At the momement, both quantum's linuxbridge plugin and nova's LinuxBridgeInterfaceDriver have an ensure_vlan_bridge() method. I'm no OpenStack expert, but I think that the nicest separation between nova's and quantum's domains is the tap device (obviously only for networks which use tap devices). Quantum should create the Linux bridge and its underlying connectivity (or even worse for ovs with security groups...), and Nova should connect a newly-created VM to it. Otherwise, Nova would have to reimplement just about any extension that is introduced to Quantum. In particular, I worry about the mapping of a network to a physical device. Quantum's linuxbridge does it according to a preconfigured cfg.CONF.LINUX_BRIDGE.physical_interface_mappings. Does Nova's vif driver support something like this? From where does it collect this information? Anyway, would you suggest oVirt to implement its own ensure_vlan_bridge()? Or use the vif driver code? Or that of linuxbridge quantum plugin? > So I'm not inclined to support this disconnected mode. Disconnected mode exists in actuality. It has valid use cases in the virtual world as well. I would like to discuss the domxml schema for representing it, and then, hopefully find the menpower to implement it outside the core libvirt team. So please, reconsider. Regards, Dan. -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] configuring a disconnected
Hi List, Like most of us, I've bought my actual computer with an Ethernet interface card, that I can connect to a wall jack at will. It's quite easy to disconnect the Ethernet cable from the wall, as well. I would like to expose this behavior to virtual computers, too. Via libvirt, of course. That's useful, since an admin may need to disconnect a running VM from a network temporarily, without resorting to hot-unplugging its nic. How should the domxml represent this situation? An interface that is connected to a specific LAN1 bridge is Would the following make sense for an interface with no bridge at the source? And how about the recommended config for s, which is type='network'? Would it make sense to predefine null-bridge-network so that means "keep this interface dangling out there"? Regards, Dan. -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] feature suggestion: migration network
On Thu, Jan 10, 2013 at 10:45:42AM +0800, Mark Wu wrote: > On 01/08/2013 10:46 PM, Yaniv Kaul wrote: > >On 08/01/13 15:04, Dan Kenigsberg wrote: > >>There's talk about this for ages, so it's time to have proper discussion > >>and a feature page about it: let us have a "migration" network role, and > >>use such networks to carry migration data > >> > >>When Engine requests to migrate a VM from one node to another, the VM > >>state (Bios, IO devices, RAM) is transferred over a TCP/IP connection > >>that is opened from the source qemu process to the destination qemu. > >>Currently, destination qemu listens for the incoming connection on the > >>management IP address of the destination host. This has serious > >>downsides: a "migration storm" may choke the destination's management > >>interface; migration is plaintext and ovirtmgmt includes Engine which > >>sits may sit the node cluster. > >> > >>With this feature, a cluster administrator may grant the "migration" > >>role to one of the cluster networks. Engine would use that network's IP > >>address on the destination host when it requests a migration of a VM. > >>With proper network setup, migration data would be separated to that > >>network. > >> > >>=== Benefit to oVirt === > >>* Users would be able to define and dedicate a separate network for > >> migration. Users that need quick migration would use nics with high > >> bandwidth. Users who want to cap the bandwidth consumed by migration > >> could define a migration network over nics with bandwidth limitation. > >>* Migration data can be limited to a separate network, that has no > >> layer-2 access from Engine > >> > >>=== Vdsm === > >>The "migrate" verb should be extended with an additional parameter, > >>specifying the address that the remote qemu process should listen on. A > >>new argument is to be added to the currently-defined migration > >>arguments: > >>* vmId: UUID > >>* dst: management address of destination host > >>* dstparams: hibernation volumes definition > >>* mode: migration/hibernation > >>* method: rotten legacy > >>* ''New'': migration uri, according to > >>http://libvirt.org/html/libvirt-libvirt.html#virDomainMigrateToURI2 > >>such as tcp:// > >> > >>=== Engine === > >>As usual, complexity lies here, and several changes are required: > >> > >>1. Network definition. > >>1.1 A new network role - not unlike "display network" should be > >> added.Only one migration network should be defined on a cluster. > >>1.2 If none is defined, the legacy "use ovirtmgmt for migration" > >> behavior would apply. > >>1.3 A migration network is more likely to be a ''required'' network, but > >> a user may opt for non-required. He may face unpleasant > >>surprises if he > >> wants to migrate his machine, but no candidate host has the network > >> available. > >>1.4 The "migration" role can be granted or taken on-the-fly, when hosts > >> are active, as long as there are no currently-migrating VMs. > >> > >>2. Scheduler > >>2.1 when deciding which host should be used for automatic > >> migration, take into account the existence and availability of the > >> migration network on the destination host. > >>2.2 For manual migration, let user migrate a VM to a host with no > >> migration network - if the admin wants to keep jamming the > >> management network with migration traffic, let her. > >> > >>3. VdsBroker migration verb. > >>3.1 For the a modern cluster level, with migration network defined on > >> the destination host, an additional ''miguri'' parameter > >>should be added > >> to the "migrate" command > >> > >>___ > >>Arch mailing list > >>a...@ovirt.org > >>http://lists.ovirt.org/mailman/listinfo/arch > > > >How is the authentication of the peers handled? Do we need a cert > >per each source/destination logical interface? > >Y. > In my understanding, using a separate migration network doesn't > change the current peers authentication. We still use the URI > ''qemu+tls://remoeHost/system' to connect the target libvirt service > if ssl enabled, and the remote host should be the ip address of > management interface. But we can choose other interfaces except the > manage interface to transport the migration data. We just change the > migrateURI, so the current authentication mechanism should still > work for this new feature. vdsm-vdsm and libvirt-libvirt communication is authenticated, but I am not sure at all that qemu-qemu communication is. After qemu is sprung up on the destination with -incoming : , anything with access to that address could hijack the process. Our migrateURI starts with "tcp://" with all the consequences of this. That a good reason to make sure has as limited access as possible. But maybe I'm wrong here, and libvir-list can show me the light. Dan. -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Users] Vdsm/libvir error during deploy
On Mon, Dec 24, 2012 at 02:18:48PM +0100, Joop wrote:
> Dan Kenigsberg wrote:
> >Which version of libvirt is installed on your host?
> >
> libvirt-1.0.1-2.fc17.x86_64
> libvirt-client-1.0.1-2.fc17.x86_64
> libvirt-daemon-1.0.1-2.fc17.x86_64
> libvirt-daemon-config-network-1.0.1-2.fc17.x86_64
> libvirt-daemon-config-nwfilter-1.0.1-2.fc17.x86_64
> libvirt-daemon-driver-interface-1.0.1-2.fc17.x86_64
> libvirt-daemon-driver-lxc-1.0.1-2.fc17.x86_64
> libvirt-daemon-driver-network-1.0.1-2.fc17.x86_64
> libvirt-daemon-driver-nodedev-1.0.1-2.fc17.x86_64
> libvirt-daemon-driver-nwfilter-1.0.1-2.fc17.x86_64
> libvirt-daemon-driver-qemu-1.0.1-2.fc17.x86_64
> libvirt-daemon-driver-secret-1.0.1-2.fc17.x86_64
> libvirt-daemon-driver-storage-1.0.1-2.fc17.x86_64
> libvirt-daemon-driver-uml-1.0.1-2.fc17.x86_64
> libvirt-daemon-driver-xen-1.0.1-2.fc17.x86_64
> libvirt-lock-sanlock-1.0.1-2.fc17.x86_64
> libvirt-python-1.0.1-2.fc17.x86_64
>
> From virt-preview repo
> [fedora-virt-preview]
> name=Virtualization packages from Rawhide built for latest Fedora
> baseurl=http://fedorapeople.org/groups/virt/virt-preview/fedora-$releasever/$basearch
> enabled=1
> skip_if_unavailable=1
> gpgcheck=0
>
> >What is the output of the following python script on your machine? Mine
> >says "1". Could it be that your libvirt says "0"?
> >
> >=
> >
> >from vdsm import libvirtconnection
> >
> >conn = libvirtconnection.get()
> >netXml = """
> > test
> >
> >
> >
> >
> >"""
> >
> >net = conn.networkDefineXML(netXml)
> >net.create()
> >print net.isPersistent()
> >net.destroy()
> >net.undefine()
> >
> >
> 0
> libvir: Network Driver error : Network not found: no network with
> matching uuid
> Traceback (most recent call last):
> File "test.py", line 16, in
>net.undefine()
> File "/usr/lib64/python2.7/site-packages/libvirt.py", line 2154, in
> undefine
>if ret == -1: raise libvirtError ('virNetworkUndefine() failed',
> net=self)
> libvirt.libvirtError: Network not found: no network with matching uuid
>
> So '0' :-((
> Suppose that error isn't good either.
> Should I downgrade to an earlier version of libvirt?
Please try. My guess is that this is a libvirt bug added by
http://libvirt.org/git/?p=libvirt.git;a=commitdiff;h=0211fd6e04cdc402da20818df54299c6ded3d3cb
in libvirt 1.0.1. More authoritative answer is expected by those added
to the CC line.
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] only 256 active networks
On Sat, Sep 29, 2012 at 11:29:45PM -0400, Laine Stump wrote: > On 09/29/2012 04:22 PM, Dan Kenigsberg wrote: > > Hi List, Laine, > > > > Maybe you can help here. > > > > We define 256 bridged networks such as > > > > > > vdsm-test244 > > c3acd4c3-37be-3f9d-ee6b-317513015f9e > > > > > > > > > > and end up killing `virsh net-list` with > > > > error: Failed to list active networks > > error: too many remote undefineds: 257 > 256 > > error: Reconnected to the hypervisor > > > > What is this limitation? Why is it there? How can this be extended/avoided? > > What version of libvirt are you running? This is a limit set by the RPC > code, and it was increased from 256 to 16384 in commit > eb635de1fed3257c5c62b552d1ec981c9545c1d7, which looks like it would be > in any libvirt *after* 0.9.12 (so any 0.10.x will have the increase). It was libvirt-0.9.10, sorry for not stating this in the original post (I hate it when people do this to me...) Regards, Dan. -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] only 256 active networks
Hi List, Laine, Maybe you can help here. We define 256 bridged networks such as vdsm-test244 c3acd4c3-37be-3f9d-ee6b-317513015f9e and end up killing `virsh net-list` with error: Failed to list active networks error: too many remote undefineds: 257 > 256 error: Reconnected to the hypervisor What is this limitation? Why is it there? How can this be extended/avoided? Dan. -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] adding handling EINTR to poll to make it more robust
On Thu, Jul 19, 2012 at 09:49:41AM +0800, Royce Lv wrote:
> some system call and signal will interrupt poll,
> making event loop stops and fails to react events and keepalive message
> from libvirt.
> adding handling EINTR to poll to make it more robust
>
> Signed-off-by: Royce Lv
> ---
> examples/domain-events/events-python/event-test.py | 87
> +++-
> 1 file changed, 46 insertions(+), 41 deletions(-)
>
> diff --git a/examples/domain-events/events-python/event-test.py
> b/examples/domain-events/events-python/event-test.py
> index 96dc268..6b655cd 100644
> --- a/examples/domain-events/events-python/event-test.py
> +++ b/examples/domain-events/events-python/event-test.py
> @@ -178,48 +178,53 @@ class virEventLoopPure:
> def run_once(self):
> sleep = -1
> self.runningPoll = True
> -next = self.next_timeout()
> -debug("Next timeout due at %d" % next)
> -if next > 0:
> -now = int(time.time() * 1000)
> -if now >= next:
> -sleep = 0
> -else:
> -sleep = (next - now) / 1000.0
> -
> -debug("Poll with a sleep of %d" % sleep)
> -events = self.poll.poll(sleep)
> -
> -# Dispatch any file handle events that occurred
> -for (fd, revents) in events:
> -# See if the events was from the self-pipe
> -# telling us to wakup. if so, then discard
> -# the data just continue
> -if fd == self.pipetrick[0]:
> -self.pendingWakeup = False
> -data = os.read(fd, 1)
> -continue
> -
> -h = self.get_handle_by_fd(fd)
> -if h:
> -debug("Dispatch fd %d handle %d events %d" % (fd,
> h.get_id(), revents))
> -h.dispatch(self.events_from_poll(revents))
> -
> -now = int(time.time() * 1000)
> -for t in self.timers:
> -interval = t.get_interval()
> -if interval < 0:
> -continue
> +try:
> +next = self.next_timeout()
> +debug("Next timeout due at %d" % next)
> +if next > 0:
> +now = int(time.time() * 1000)
> +if now >= next:
> +sleep = 0
> +else:
> +sleep = (next - now) / 1000.0
> +
> +debug("Poll with a sleep of %d" % sleep)
> +events = self.poll.poll(sleep)
> +
> +# Dispatch any file handle events that occurred
> +for (fd, revents) in events:
> +# See if the events was from the self-pipe
> +# telling us to wakup. if so, then discard
> +# the data just continue
> +if fd == self.pipetrick[0]:
> +self.pendingWakeup = False
> +data = os.read(fd, 1)
> +continue
> +
> +h = self.get_handle_by_fd(fd)
> +if h:
> +debug("Dispatch fd %d handle %d events %d" % (fd,
> h.get_id(), revents))
> +h.dispatch(self.events_from_poll(revents))
>
> -want = t.get_last_fired() + interval
> -# Deduct 20ms, since schedular timeslice
> -# means we could be ever so slightly early
> -if now >= (want-20):
> -debug("Dispatch timer %d now %s want %s" % (t.get_id(),
> str(now), str(want)))
> -t.set_last_fired(now)
> -t.dispatch()
> -
> -self.runningPoll = False
> +now = int(time.time() * 1000)
> +for t in self.timers:
> +interval = t.get_interval()
> +if interval < 0:
> +continue
> +
> +want = t.get_last_fired() + interval
> +# Deduct 20ms, since scheduler timeslice
> +# means we could be ever so slightly early
> +if now >= (want-20):
> +debug("Dispatch timer %d now %s want %s" % (t.get_id(),
> str(now), str(want)))
> +t.set_last_fired(now)
> +t.dispatch()
> +
> +except (os.error, select.error), e:
> +if e.args[0] != errno.EINTR:
> +raise
> +finally:
> +self.runningPoll = False
Thanks, I'm happy with this version.
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] qemu: Do not fail virConnectCompareCPU if host CPU is not known
On Thu, Jul 12, 2012 at 01:06:08PM +0200, Jiri Denemark wrote:
> When host CPU could not be properly detected, virConnectCompareCPU will
> just report that any CPU is incompatible with host CPU instead of
> failing.
> ---
> src/qemu/qemu_driver.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
> index dc04d13..6d3b8d5 100644
> --- a/src/qemu/qemu_driver.c
> +++ b/src/qemu/qemu_driver.c
> @@ -9419,8 +9419,8 @@ qemuCPUCompare(virConnectPtr conn,
> qemuDriverLock(driver);
>
> if (!driver->caps || !driver->caps->host.cpu) {
> -qemuReportError(VIR_ERR_OPERATION_INVALID,
> -"%s", _("cannot get host CPU capabilities"));
> +VIR_WARN("cannot get host CPU capabilities");
> +ret = VIR_CPU_COMPARE_INCOMPATIBLE;
> } else {
> ret = cpuCompareXML(driver->caps->host.cpu, xmlDesc);
> }
Jiri, I think that I've changed my own taste about this, too.
I don't know what can lead driver->caps to be NULL, but I support that
many things that are unrelated to host CPU can.
If this is the case, the caller of cpuCompareXML may receive a
misleading VIR_CPU_COMPARE_INCOMPATIBLE. Limiting the new ret to the
case of driver->caps->host.cpu == NULL would have been better.
But again: is there a chance that driver->caps->host.cpu is NULL due to
lack of memory during host probing?
I'm still wondering why libvirt must detect a known hardware cpu on the
host. In the age of nested virt, it may find more bizarre combinations,
that it may be interesting to support.
Dan.
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] add handling EINTR to test example of event loop
On Mon, Jun 18, 2012 at 10:56:26AM +0100, Daniel P. Berrange wrote:
> On Mon, Jun 18, 2012 at 05:43:55PM +0800, lvro...@linux.vnet.ibm.com wrote:
> > From: lvroyce
> >
> > some system call and signal will interrupt poll,
> > making event loop stops and fails to react events and keepalive message
> > from libvirt.
> > adding handling EINTR to poll to make it more robust
> >
> > Signed-off-by: lvroyce
> > ---
> > examples/domain-events/events-python/event-test.py |8 +++-
> > 1 files changed, 7 insertions(+), 1 deletions(-)
> >
> > diff --git a/examples/domain-events/events-python/event-test.py
> > b/examples/domain-events/events-python/event-test.py
> > index 96dc268..b446c21 100644
> > --- a/examples/domain-events/events-python/event-test.py
> > +++ b/examples/domain-events/events-python/event-test.py
> > @@ -188,7 +188,13 @@ class virEventLoopPure:
> > sleep = (next - now) / 1000.0
> >
> > debug("Poll with a sleep of %d" % sleep)
> > -events = self.poll.poll(sleep)
> > +try:
> > +events = self.poll.poll(sleep)
> > +except select.error, e:
> > +self.runningPoll = False
> > +if not e.errno in (errno.EINTR, errno.EAGAIN):
> > +raise
> > +return
>
> It isn't possible for poll() to return EAGAIN according to the
> manpage.
>
> If you remove that errno, then the patch would be ok. Also the
> indentation in the except: block is too deep - line it up with
> the try: block
The same function has another possible exception-raiser: os.read() few
lines below, and probably others. How about putting
self.runningPoll = False
in a "finally" clause opened right after the first self.runningPoll
assignment?
Dan
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] qemu: configurable VNC port boundaries for domains
On Wed, May 23, 2012 at 10:31:12AM +0100, Daniel P. Berrange wrote: > On Tue, May 22, 2012 at 11:00:16AM -0400, Dave Allan wrote: > > On Tue, May 22, 2012 at 04:10:03PM +0200, Martin Kletzander wrote: > > > The defines QEMU_VNC_PORT_MIN and QEMU_VNC_PORT_MAX were used to find > > > free port when starting domains. As this was hardcoded to the same > > > ports as default VNC servers, there were races with these other > > > programs. This patch includes the possibility to change the default > > > starting port as well as the maximum port in qemu config file. > > > > Hi Martin, > > > > Two design comments: > > > > 1) https://bugzilla.redhat.com/show_bug.cgi?id=782814 requests that > > the default port be changed to avoid conflicts, which seems reasonable > > to me. > > I disagree - for as long as KVM and Xen have existed, all guests have > had ports starting at 5900 & we should not be changing that. libvirt > should be checking for a clash before starting a guest, so there should > not be any functional problem here. I'm not sure how libvirt does this today, but passing the port in the command line is inherently raceful. Either pass the open socket to qemu, or let qemu choose the port by itself. > Moving to another port range is > merely a nicety that we don't need todo by default, merely give admins > the ability. > > > > > 2) I agree with the config option since most applications on the > > system will want the system defaults. However, IMO in this case an > > application writer should be given the option in the XML to override > > the system default. > > I don't really think this is worth while either. I don't really think > that apps need / want the ability to override the system ranges here > on a per guest basis Yep, that's true for vdsm too (within ovirt). I can tell why host-wide config is useful, but not why the range should be VM-specific. Regards, Dan. -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] F17's libvirt takes comments into LIBVIRTD_ARGS
On Wed, May 16, 2012 at 11:05:16PM +0800, Shu Ming wrote: > On 2012-5-16 18:46, Dan Kenigsberg wrote: > >On Tue, May 15, 2012 at 04:16:11PM +0800, Shu Ming wrote: > >>On 2012-5-14 7:30, Dan Kenigsberg wrote: > >>>On Sun, May 13, 2012 at 11:51:48PM +0800, Shu Ming wrote: > >>>>Hi, > >>>> Recently, I found that my host in engine was always in a > >>>>"unassigned state" after the host node was installed. After looking > >>>>into the vdsm.log, it seemed that vdsm failed to call libvirt as an > >>>>error, "libvirtError: Cannot write data: Broken pipe". When I > >>>>started virsh in the host node at that time, a warning was given > >>>>"WARNING: no socket to connect to" and core dumped with "virsh > >>>>net-list". It looks like that no right socket was created for > >>>>virsh to connect to libvirtd. Any comments about this problem? The > >>>>followings are my steps in the node: > >>>> > >>>>[root@ovirt-node1 ~]# rpm -qa |grep vdsm > >>>>vdsm-cli-4.9.6-0.183.git107644d.fc16.shuming1336622293.noarch > >>>>vdsm-python-4.9.6-0.183.git107644d.fc16.shuming1336622293.noarch > >>>>vdsm-hook-vhostmd-4.9.6-0.183.git107644d.fc16.shuming1336622293.noarch > >>>>vdsm-4.9.6-0.183.git107644d.fc16.shuming1336622293.x86_64 > >>>>vdsm-reg-4.9.6-0.183.git107644d.fc16.shuming1336622293.noarch > >>>>vdsm-debug-plugin-4.9.6-0.183.git107644d.fc16.shuming1336622293.noarch > >>>>vdsm-hook-faqemu-4.9.6-0.183.git107644d.fc16.shuming1336622293.noarch > >>>>vdsm-bootstrap-4.9.6-0.183.git107644d.fc16.shuming1336622293.noarch > >>>>[root@ovirt-node1 ~]# > >>>>[root@ovirt-node1 ~]# ps -ef |grep libvirt > >>>> > >>>>libvirt-daemon-0.9.11-1.fc17.x86_64 > >>>>libvirt-daemon-config-nwfilter-0.9.11-1.fc17.x86_64 > >>>>libvirt-client-0.9.11-1.fc17.x86_64 > >>>>libvirt-daemon-config-network-0.9.11-1.fc17.x86_64 > >>>>libvirt-python-0.9.11-1.fc17.x86_64 > >>>> > >>>>[root@ovirt-node1 ~]# virsh net-list > >>>>WARNING: no socket to connect to > >>>>Segmentation fault > >>>I think that merits a libvirt bug. please attach strace output to > >>>bugzilla. > >>> > >>>>[root@ovirt-node1 ~]# > >>>> > >>>> > >>>>[root@ovirt-node1 ~]# ps -ef |grep vdsm > >>>>root 1299 1 0 23:10 ?00:00:00 /usr/sbin/libvirtd > >>>>--listen # by vdsm > >>>The command line of libvirt process is very odd - the comment that vdsm > >>>puts into /etc/sysconfig/libvirtd is somehow taken verbatim. That's bad, > >>>and may be related to Fedora 17's systemd services. Try to remove the > >>>comment and restart libvirtd to see if this is the case. > >>The comment come from > >> > >>[root@ovirt-node1 ~]# cat /etc/sysconfig/libvirtd: > >I know that (see my text above). However, in F16 and before, comments have > >been stripped > >before being passed to commandline. Have you tested if all is well when > >the commment is removed? > > I removed the "# by vdsm " line from the config file. And > restarted the libvirtd and vdsmd service. > But no luck to make "virsh net-list" successful, still got > "Segmentation fault", while "virsh -c qemu:///system -r" worked. Thanks. Please strace that segfault, there's a libvirt bug lying there. And thanks again for finding the vdsm/libvirt configuration problem in F17. -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] F17's libvirt takes comments into LIBVIRTD_ARGS
On Tue, May 15, 2012 at 04:16:11PM +0800, Shu Ming wrote: > On 2012-5-14 7:30, Dan Kenigsberg wrote: > >On Sun, May 13, 2012 at 11:51:48PM +0800, Shu Ming wrote: > >>Hi, > >> Recently, I found that my host in engine was always in a > >>"unassigned state" after the host node was installed. After looking > >>into the vdsm.log, it seemed that vdsm failed to call libvirt as an > >>error, "libvirtError: Cannot write data: Broken pipe". When I > >>started virsh in the host node at that time, a warning was given > >>"WARNING: no socket to connect to" and core dumped with "virsh > >>net-list". It looks like that no right socket was created for > >>virsh to connect to libvirtd. Any comments about this problem? The > >>followings are my steps in the node: > >> > >>[root@ovirt-node1 ~]# rpm -qa |grep vdsm > >>vdsm-cli-4.9.6-0.183.git107644d.fc16.shuming1336622293.noarch > >>vdsm-python-4.9.6-0.183.git107644d.fc16.shuming1336622293.noarch > >>vdsm-hook-vhostmd-4.9.6-0.183.git107644d.fc16.shuming1336622293.noarch > >>vdsm-4.9.6-0.183.git107644d.fc16.shuming1336622293.x86_64 > >>vdsm-reg-4.9.6-0.183.git107644d.fc16.shuming1336622293.noarch > >>vdsm-debug-plugin-4.9.6-0.183.git107644d.fc16.shuming1336622293.noarch > >>vdsm-hook-faqemu-4.9.6-0.183.git107644d.fc16.shuming1336622293.noarch > >>vdsm-bootstrap-4.9.6-0.183.git107644d.fc16.shuming1336622293.noarch > >>[root@ovirt-node1 ~]# > >>[root@ovirt-node1 ~]# ps -ef |grep libvirt > >> > >>libvirt-daemon-0.9.11-1.fc17.x86_64 > >>libvirt-daemon-config-nwfilter-0.9.11-1.fc17.x86_64 > >>libvirt-client-0.9.11-1.fc17.x86_64 > >>libvirt-daemon-config-network-0.9.11-1.fc17.x86_64 > >>libvirt-python-0.9.11-1.fc17.x86_64 > >> > >>[root@ovirt-node1 ~]# virsh net-list > >>WARNING: no socket to connect to > >>Segmentation fault > >I think that merits a libvirt bug. please attach strace output to > >bugzilla. > > > >>[root@ovirt-node1 ~]# > >> > >> > >>[root@ovirt-node1 ~]# ps -ef |grep vdsm > >>root 1299 1 0 23:10 ?00:00:00 /usr/sbin/libvirtd > >>--listen # by vdsm > >The command line of libvirt process is very odd - the comment that vdsm > >puts into /etc/sysconfig/libvirtd is somehow taken verbatim. That's bad, > >and may be related to Fedora 17's systemd services. Try to remove the > >comment and restart libvirtd to see if this is the case. > The comment come from > > [root@ovirt-node1 ~]# cat /etc/sysconfig/libvirtd: I know that (see my text above). However, in F16 and before, comments have been stripped before being passed to commandline. Have you tested if all is well when the commment is removed? Let's see what our friends in libvir-list think. Dan. -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [vdsm] non-TLS spice connections
On Tue, Feb 21, 2012 at 05:17:50PM +0100, Christophe Fergeau wrote: > Hi, > > On Tue, Feb 21, 2012 at 06:09:06PM +0200, Dan Kenigsberg wrote: > > Please note Bug 788092 - VDSM: Disable vdsm's ssl'ability influence > > spice ssl'ability and prevent VM from starting > > https://bugzilla.redhat.com/show_bug.cgi?id=788092#c1 > > > > Could it be that you have ssl=false in your vdsm.conf? > > I've got ssl=true in my vdsm.conf, and the VM starts properly (qemu is > running after I start it in the web interface) so it's probably a slightly > different issue I'm hitting. I understand that the issue appears to be a former Vdsm configuring listen_tls=0 in qemu.conf, but Vdsm being asked to start a VM with secure spice channels. >From Vdsm's point of view, it would be nice if libvirt/qemu protected us from this situation, by not letting such a VM to start. But as I think of this further, I'm not sure - if a iron-made computer has a broken screen, I would still expect it to boot and answer the network. Would it similarly make sense for a VM to start when its qxl device is inaccessible to the world? Anyway, I believe that once Vdsm stops messing with spice's listen_tls just because Vdsm has ssl=false, the problem at hand would disappear. Dan. -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [vdsm] non-TLS spice connections
On Tue, Feb 21, 2012 at 04:53:24PM +0100, Christophe Fergeau wrote: > Hey, > > I recently setup ovirt/vdsm on one of my boxes. For some reason spice TLS > was disabled through spice_tls = no in /etc/libvirt/qemu.conf. > Then I created a VM, started it, and had troubles connecting to it with > spicec. After investigating (thanks djasa), I realized that qemu was > started with some encrypted SPICE channels but with no TLS port configured, > which explained why I couldn't connect. > > https://bugzilla.redhat.com/show_bug.cgi?id=790436 was filed against > libvirt about this, but now we are wondering how to best fix things in > libvirt. > > What is currently happening is that libvirt doesn't warn when a domain has > with spice_tls = no in qemu.conf, and > it adds the corresponding tls-channel=main to qemu command-line, but > doesn't set a TLS port (if one is set it's silently ignored). > > There are at least two ways of solving this problem in libvirt: > * either the current behaviour is kept, but "tls-channel=main" is not > added to qemu command line when spice-tls is disabled. The drawback of > this is that some security options that have been explicitly set in the > domain XML are silently ignored > * or the current behaviour is changed, and in this situation (SPICE secure > channels in the XML, but TLS disabled in qemu.conf), libvirt errors out, > which would change the current behaviour. > > This has been discussed on the libvirt mailing list (cc'ed) in this thread: > https://www.redhat.com/archives/libvir-list/2012-February/msg00656.html > > Before making a decision, we were wondering what behaviour oVirt > would expect in this case (error or silently ignoring the secure channels), > and if a setup with spice_tls = no in /etc/libvirt/qemu.conf is something > widely deployed that you have to support, or if it's more of an > experimental feature at this point. > > Thanks for any input you can give on this matter, > > Christophe Please note Bug 788092 - VDSM: Disable vdsm's ssl'ability influence spice ssl'ability and prevent VM from starting https://bugzilla.redhat.com/show_bug.cgi?id=788092#c1 Could it be that you have ssl=false in your vdsm.conf? -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 2/2] Don't kill QEMU process when a monitor I/O parsing error occurs
On Wed, May 11, 2011 at 12:59:07PM +0100, Daniel P. Berrange wrote: > > > +/* > + * This is invoked when there is some kind of error > + * parsing data to/from the monitor. The VM can continue > + * to run, but no further monitor commands will be > + * allowed > + */ > +static void > +qemuProcessHandleMonitorError(qemuMonitorPtr mon ATTRIBUTE_UNUSED, > + virDomainObjPtr vm) I'm all for being graceful and polite, so this sounds good. However, events are bound to be lost. The solution would be more robust if there was a way to query the state of the monitor (though I'm not sure it is worth the hassle). PS, I wonder what VMM stands for in this context. Not virtual memory manager, I suppose. Since I've only read the comments, not the code, I wonder if the 'quit' command is still passed to the monitro even after an error occured. Without it, we'd have to resort to SIGTERM/SIGKILL, which is less graceful. -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] migration of vnlink VMs
On Wed, May 11, 2011 at 01:37:25PM +0100, Daniel P. Berrange wrote: > On Wed, May 11, 2011 at 03:28:30PM +0300, Dan Kenigsberg wrote: > > Sorry for hijacking the thread for something more general than vnlink: > > > > > > It just occured to me today that the concept of virtual network should > > be used also in the section. Currently, if you specify > > you make the domain practically > > unmigratable. > > > > There should be a method to specify a simbolic network name, to be > > evaluated to IP on the destination host, something like > > > > > > Yep, I pretty much agree, but we'll need more help from QEMU > todo that. A virtual network may have multiple IP addresses > and so we'll need to be able to specify multiple IPs to the > VNC server. That would be nice, but I think that a semantics where libvirt is in charge of telling which qemu process is to listen on which of the network IP addresses is as reasonable (and may potentially better, as libvirt has more knowledge of the host) Anyway, if the virtual network is bridge-based, I could live with passing the single IP of the bridge for qemus that do not support this feature. Regards, Dan. -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] migration of vnlink VMs
Sorry for hijacking the thread for something more general than vnlink: It just occured to me today that the concept of virtual network should be used also in the section. Currently, if you specify you make the domain practically unmigratable. There should be a method to specify a simbolic network name, to be evaluated to IP on the destination host, something like Regards, Dan. -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] libvirt commands during migration
Hi, We've noticed that most of libvirt domain-specific calls block while qemu is migrating. Isn't it kind-of-a-bug? Migration can take a while; qemu allows to do it in the background, and accepts monitor commands. So why should a libvirt user be blocked from his favorite domblkstat? Regards, Dan. -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] RFC: virInterface change transaction API
On Mon, Apr 18, 2011 at 05:53:05PM +0100, Daniel P. Berrange wrote: > On Thu, Apr 14, 2011 at 04:03:03PM +0300, Dan Kenigsberg wrote: > > On Fri, Apr 08, 2011 at 03:31:05PM -0400, Laine Stump wrote: > > > I've been asked to implement what some people have termed as a > > > "transaction-oriented" API for host interface configuration (ie > > > virInterface*()). > > > The basic intent is to allow rollback to a known-good config if > > > anything goes > > > wrong when changing around the host network config with virInterface*() > > > functions. > > > > > > The most straightforward way to achieve this is that prior to calling > > > virInterfaceDefine/virInterfaceUndefine, the current state of the > > > host's network configuration (ie the > > > /etc/sysconfig/network-scripts/ifcfg-* > > > files in the case of Fedora and RHEL) would be saved off somewhere, and > > > kept around until we're sure the new config is good; once we know that, > > > we can just eliminate the backup. If, however, the user of virInterface*() > > > explicitly requests, we could copy the files back; alternately if the > > > system > > > is rebooted without these known-good files being erased, we would assume > > > that something went wrong and restore the original config. > > > > > > As with all other virInterface functions, the details of all this will > > > be handled by netcf (and below), but since libvirt is the main consumer > > > of netcf, I figure this is the appropriate place to discuss how it > > > gets done, > > > so please let me know any opinions on any piece of this. I plan to start > > > the implementation "soon", as I want to be finished before the end of > > > May. > > > > I like the idea, and think that virtInterface* users will benefit from it. > > Few comments are inline. > > > > > > > > I see 3 layers to this: > > > > > > 1) libvirt > > > > > >At the libvirt layer, this feature just requires 3 new APIs, which > > >are directly passed through to netcf: > > > > > >virInterfaceChangeStart(virConnectPtr conn, unsigned int flags); > > >virInterfaceChangeCommit(virConnectPtr conn, unsigned int flags); > > >virInterfaceChangeRollback(virConnectPtr conn, unsigned int flags); > > > > > >For the initial implementation, these will be simple passthroughs > > >to similarly named netcf functions. (in the future, it would be > > >useful for the server side of libvirt to determine if client<->server > > >connectivity was lost due to the network changes, and automatically > > >tell netcf to do a rollback). > > > > When such a feature is added, we should make it dependent on > > FLAG_AUTO_ROLLBACK > > passed to ChangeStart. Higher levels on the management stack may want full > > controll over when rollback happens. > > I don't think a AUTO_ROLLBACK flag is sufficient. You'd almost certainly > want to pass some info such as hostname/port number to test, and perhaps > a test timeout in milliseconds, and perhaps a retry count. Yes, that's why I wanted complete control over auto rollback, when it is inroduced. > I suggest a > separate API that is invoked just after starting the TXN, to provide > auto-rollback data. > > Regards, > Daniel > -- > |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| > |: http://libvirt.org -o- http://virt-manager.org :| > |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| > |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] RFC: virInterface change transaction API
more exact operation worth the extra complexity?
(A) is simpler? Or did you mean (B)? I'm slightly worried about (B) causing
disconnection of completely unrelated interfaces; this may break concurrent
applications, or even the user of netcf.
>
>
>
> ncf_change_commit(struct netcf *ncf, unsigned int flags);
>
> The simplest function - this will just call the initscript
> to erase the backup (commit_config).
>
>
> 3) initscript
>
>This initscript will at first live in (be installed by) netcf
>(called /etc/init.d/networking-config?), but hopefully it will
>eventually be accepted by the initscripts package (which includes
>the networking-related initscripts), as it is of general use. (Dan
>Kenigsberg already already took a stab at this script last year,
>but received no reply from the initscripts maintainers, implying
>they may not be too keen on the idea right now - it might take some
>convincing ;-)
>
> https://fedorahosted.org/pipermail/initscripts-devel/2010-February/25.html
>
>It will have three commands, one of which will be called
>automatically by "start" (the command called automatically at boot
>time):
>
>snapshot_config
>
> This will save a copy of (what the script believes are - is this
> problematic?) all network-config related files. It may or may not
> be called by netcf (see the notes in ncf_start_change() above.
>
> If this function finds that a snapshot has already been taken,
> it should fail.
>
>
>rollback_config (automatically called from "start" at boottime)
>
> This will move back (from the saved copies) all files that were
> changed/removed since snapshot, *and delete any files that have
> been added*.
>
> Note that this command doesn't need to worry about ifup/ifdown,
> because it will be called prior to any other networking startup
> (part of the reason that netcf will need to deal with that).
>
> I notice that Dan K's version saves the modified files to a
> "rollback-${date}" directory. Does this seem like a good idea?
> It's nice to not lose anything, but there is no provision for
> eliminating old versions, so it could grow without bound.
I sleep better at night when there are backups... Obviously, I should not have
kept them beyond a certain limit (last 20). And I'd understand if you think that
it is the business of a backup system, or conf management system, to take theses
backups.
>
>commit_config
>
> This will just remove all the files in the save directory.
>
>
> So, the two problems I have right now:
>
> 1) Do we accept the inexact method of just saving all files that match
>a list of patterns during *start(), then in *rollback() erasing all
>files matching that pattern and copying the old file back? Or do we
>need to keep track of what files have been changed/removed and added,
>and copy back / delete only those files during rollback?
>
>(A version control system would keep track of this rather nicely,
>but that's too complex for something that's intended to be a
>failsafe (and that we would also like to eventually be in the base
>OS install). Dan B. at one point suggested using patchfiles if I
>wanted the save info to keep exact track of which files would need
>to be replaced/deleted on rollback, but on further thought this
>turns out to not be workable, since we would need to run diff (to
>create the patchfile) after all changes had been made, and any
>outside changes to any of the files would leave the patchfile
>un-appliable, thus causing our "failsafe" to fail :-( ). Therefore,
>we will need to rely on the list of globs to tell us what files
>need to be deleted, or keep our own list in a separate file.)
>
> 2) Is it going to be okay to ifdown all interfaces prior to the
>rollback, and ifup all interfaces afterwards? Or must we compare
>the new config to the original, and ifdown only those interfaces
>that had been previously added/changed, then ifup only those
>interfaces that had been previously removed/changed?
>
> 3) If anyone has ideas on making the initscript more palatable to the
>initscripts people, please speak up! :-) (one comment from an
> initscripts
>person was that 1) for the general case it would be difficult to
> draw the
>line on what parts of network connectivity should be included in this
>rollback functionality, and 2) at some point this becomes a general
>system config problem, and would really be better addressed by a
>general system wide config management system. These are both
>concerns that need well qualified answers. (I tend to think that this
>is intended as a failsafe to prevent unreachable systems, so it should
>be as simple as possible, and thus shouldn't be burdened with the
>complexity of a full system config management system (which could
>also co-exist at a higher level), but better answers are welcome.)
>
> --
> libvir-list mailing list
> libvir-list@redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 2/2] virt-*-validate.in: quote all variable references
Alas, the shell is not a real programming language.
Patch generated by manual confirmation of vim's
s/[^"]\@<=\$\S\+\s\@=/"&"/gc
and
s/\(echo \)\@<=[^"].*\$.*$/"&"/c matches.
This patch generate a lot of noise and carries little benefits, as
I do not really expect $PKI to contain spaces or backticks. I'm just
fuming, and would not really mind if this patch is ignored
---
tools/virt-pki-validate.in | 64 ++--
tools/virt-xml-validate.in | 10 +++---
2 files changed, 37 insertions(+), 37 deletions(-)
diff --git a/tools/virt-pki-validate.in b/tools/virt-pki-validate.in
index 96659cf..8a4249d 100755
--- a/tools/virt-pki-validate.in
+++ b/tools/virt-pki-validate.in
@@ -20,27 +20,27 @@ then
echo "make sure the gnutls-utils (or gnutls-bin) package is installed"
exit 1
fi
-echo Found $CERTOOL
+echo Found "$CERTOOL"
#
# Check the directory structure
#
SYSCONFDIR="@SYSCONFDIR@"
PKI="$SYSCONFDIR/pki"
-if [ ! -d $PKI ]
+if [ ! -d "$PKI" ]
then
echo the $PKI directory is missing, it is usually
echo installed as part of the filesystem or openssl packages
exit 1
fi
-if [ ! -r $PKI ]
+if [ ! -r "$PKI" ]
then
echo the $PKI directory is not readable by $USER
echo "as root do: chmod a+rx $PKI"
exit 1
fi
-if [ ! -x $PKI ]
+if [ ! -x "$PKI" ]
then
echo the $PKI directory is not listable by $USER
echo "as root do: chmod a+rx $PKI"
@@ -48,20 +48,20 @@ then
fi
CA="$PKI/CA"
-if [ ! -d $CA ]
+if [ ! -d "$CA" ]
then
echo the $CA directory is missing, it is usually
echo installed as part of the or openssl package
exit 1
fi
-if [ ! -r $CA ]
+if [ ! -r "$CA" ]
then
echo the $CA directory is not readable by $USER
echo "as root do: chmod a+rx $CA"
exit 1
fi
-if [ ! -x $CA ]
+if [ ! -x "$CA" ]
then
echo the $CA directory is not listable by $USER
echo "as root do: chmod a+rx $CA"
@@ -69,7 +69,7 @@ then
fi
LIBVIRT="$PKI/libvirt"
-if [ ! -d $LIBVIRT ]
+if [ ! -d "$LIBVIRT" ]
then
echo the $LIBVIRT directory is missing, it is usually
echo installed by the libvirt package
@@ -77,13 +77,13 @@ then
exit 1
fi
-if [ ! -r $LIBVIRT ]
+if [ ! -r "$LIBVIRT" ]
then
echo the $LIBVIRT directory is not readable by $USER
echo "as root do: chown root:root $LIBVIRT ; chmod 755 $LIBVIRT"
exit 1
fi
-if [ ! -x $LIBVIRT ]
+if [ ! -x "$LIBVIRT" ]
then
echo the $LIBVIRT directory is not listable by $USER
echo "as root do: chown root:root $LIBVIRT ; chmod 755 $LIBVIRT"
@@ -91,7 +91,7 @@ then
fi
LIBVIRTP="$LIBVIRT/private"
-if [ ! -d $LIBVIRTP ]
+if [ ! -d "$LIBVIRTP" ]
then
echo the $LIBVIRTP directory is missing, it is usually
echo installed by the libvirt package
@@ -99,13 +99,13 @@ then
exit 1
fi
-if [ ! -r $LIBVIRTP ]
+if [ ! -r "$LIBVIRTP" ]
then
echo the $LIBVIRTP directory is not readable by $USER
echo "as root do: chown root:root $LIBVIRTP ; chmod 755 $LIBVIRTP"
exit 1
fi
-if [ ! -x $LIBVIRTP ]
+if [ ! -x "$LIBVIRTP" ]
then
echo the $LIBVIRTP directory is not listable by $USER
echo "as root do: chown root:root $LIBVIRTP ; chmod 755 $LIBVIRTP"
@@ -116,7 +116,7 @@ fi
# Now check the certificates
# First the CA certificate
#
-if [ ! -f $CA/cacert.pem ]
+if [ ! -f "$CA/cacert.pem" ]
then
echo the CA certificate $CA/cacert.pem is missing while it
echo should be installed on both client and servers
@@ -124,7 +124,7 @@ then
echo on how to install it
exit 1
fi
-if [ ! -r $CA/cacert.pem ]
+if [ ! -r "$CA/cacert.pem" ]
then
echo the CA certificate $CA/cacert.pem is not readable by $USER
echo "as root do: chmod 644 $CA/cacert.pem"
@@ -135,7 +135,7 @@ sed_get_org='/Issuer:/ {
s/,.*//
p
}'
-ORG=`$CERTOOL -i --infile $CA/cacert.pem | sed -n "$sed_get_org"`
+ORG=`"$CERTOOL" -i --infile "$CA/cacert.pem" | sed -n "$sed_get_org"`
if [ "$ORG" = "" ]
then
echo the CA certificate $CA/cacert.pem does not define the organization
@@ -148,29 +148,29 @@ echo Found CA certificate $CA/cacert.pem for $ORG
# Second the client certificates
-if [ -f $LIBVIRT/clientcert.pem ]
+if [ -f "$LIBVIRT/clientcert.pem" ]
then
-if [ ! -r $LIBVIRT/clientcert.pem ]
+if [ ! -r "$LIBVIRT/clientcert.pem" ]
then
echo Client certificate $LIBVIRT/clientcert.pem should be world
readable
echo "as root do: chown root:root $LIBVIRT/clientcert.pem ; chmod 644
$LIBVIRT/clientcert.pem"
else
-S_ORG=`$CERTOOL -i --infile $LIBVIRT/clientcert.pem | grep Subject: |
sed 's+.*O=\([a-zA-Z \._-]*\).*+\1+'`
+S_ORG=`"$CERTOOL" -i --infile "$LIBVIRT/clientcert.pem" | grep
Subject: | sed 's+.*O=\([a-zA-Z \._-]*\).*+\1+'`
if [ "$ORG" != "$S_ORG" ]
then
echo The CA certificate and the client certificate do not match
echo CA organization: $ORG
echo Client organization: $S_ORG
fi
-CLIENT=
[libvirt] [PATCH 1/2] virt-pki-validate: behave when CERTTOOL is missing
--- tools/virt-pki-validate.in |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/tools/virt-pki-validate.in b/tools/virt-pki-validate.in index 207fa76..96659cf 100755 --- a/tools/virt-pki-validate.in +++ b/tools/virt-pki-validate.in @@ -14,7 +14,7 @@ PORT=16514 # First get certtool # CERTOOL=`which certtool 2>/dev/null` -if [ ! -x $CERTOOL ] +if [ ! -x "$CERTOOL" ] then echo "Could not locate the certtool program" echo "make sure the gnutls-utils (or gnutls-bin) package is installed" -- 1.7.4 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] qemu driver: initgroups after fork
Hi, I might be wrong here, but it seems that when libvirt spawns a new qemu process, it sets its uid and gid (qemu:qemu by deafult) but does not call initgroups(), so the spawned qemu cannot read files that are owned by qemu auxiliary groups. Am I right? How difficult is the fix? Dan. -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] spec: do not start libvirt-guests if that service is off
starting a service during rpm installation is impolite. It is even worse if done during upgrade, for a service that was explicitly turned off. --- libvirt.spec.in |8 +--- 1 files changed, 5 insertions(+), 3 deletions(-) diff --git a/libvirt.spec.in b/libvirt.spec.in index 48453d7..e0cab78 100644 --- a/libvirt.spec.in +++ b/libvirt.spec.in @@ -700,9 +700,11 @@ fi /sbin/ldconfig /sbin/chkconfig --add libvirt-guests if [ $1 -ge 1 ]; then -# this doesn't do anything but allowing for libvirt-guests to be -# stopped on the first shutdown -/sbin/service libvirt-guests start > /dev/null 2>&1 || true +if /sbin/chkconfig --list libvirt-guests | /bin/grep -q :on ; then +# this doesn't do anything but allowing for libvirt-guests to be +# stopped on the first shutdown +/sbin/service libvirt-guests start > /dev/null 2>&1 || true +fi fi %postun client -p /sbin/ldconfig -- 1.7.3.2 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [RFC] new preferences requirement
On Mon, Dec 06, 2010 at 10:32:21AM +, Daniel P. Berrange wrote: > On Thu, Dec 02, 2010 at 11:38:26PM +0200, Dan Kenigsberg wrote: > > On Wed, Dec 01, 2010 at 10:26:35AM +, Daniel P. Berrange wrote: > > > On Wed, Dec 01, 2010 at 05:35:38PM +0800, Osier Yang wrote: > > > > Hi, all > > > > > > > >We have some new requirements of preferences, I listed > > > > which of them I known, and think is useful as follows: > > > > > > > > 1) for the path of x509 certificate and keys of client > > > > > > > >The path of x509 certificate and keys of client is hard > > > > coded in remote driver. e.g. > > > > > > > >/* Defaults for PKI directory. */ > > > ># define LIBVIRT_PKI_DIR SYSCONFDIR "/pki" > > > ># define LIBVIRT_CACERT LIBVIRT_PKI_DIR "/CA/cacert.pem" > > > ># define LIBVIRT_CLIENTKEY LIBVIRT_PKI_DIR "/libvirt/private > > > > /clientkey.pem" > > > ># define LIBVIRT_CLIENTCERT LIBVIRT_PKI_DIR "/libvirt/clientcert.pem" > > > > > > We can't assume one set of certs/keys is suitable for all > > > URIs, so making this a preference setting doesn't help. There > > > needs to be a parameter in the URI to specify a cert/key name > > > to override the defaults on a per-connection basis > > > > As much as I disliked adding long ugly filenames to the URI, I do not > > see any way around it now. A single client application may need to open > > two connections with different cert/key pairs, so a single client.conf > > or environment variables won't cut it. > > NB, I wasn't really suggesting adding the long filenames. Instead > I'd suggest adding some cert "name" tag, and use that to formulate > the filenames according to some pattern, > > eg > $HOME/.libvirt/$name/cacert.pem > $HOME/.libvirt/$name/clientcert.pem > $HOME/.libvirt/$name/clientkey.pem (but make sure it works for homeless daemons, too) -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] Fix funny off-by-one error in clock-variable
Humans consider January as month #1, while gmtime_r(3) calls it month #0. While fixing it, render qemu's rtc parameter with leading zeros, as is more commonplace. Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=660194 --- src/qemu/qemu_conf.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/qemu/qemu_conf.c b/src/qemu/qemu_conf.c index 83c0f83..973e95b 100644 --- a/src/qemu/qemu_conf.c +++ b/src/qemu/qemu_conf.c @@ -3510,9 +3510,9 @@ qemuBuildClockArgStr(virDomainClockDefPtr def) now += def->data.adjustment; gmtime_r(&now, &nowbits); -virBufferVSprintf(&buf, "base=%d-%d-%dT%d:%d:%d", +virBufferVSprintf(&buf, "base=%d-%d-%dT%02d:%02d:%02d", nowbits.tm_year + 1900, - nowbits.tm_mon, + nowbits.tm_mon + 1, nowbits.tm_mday, nowbits.tm_hour, nowbits.tm_min, -- 1.7.3.2 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [RFC] new preferences requirement
On Wed, Dec 01, 2010 at 10:26:35AM +, Daniel P. Berrange wrote: > On Wed, Dec 01, 2010 at 05:35:38PM +0800, Osier Yang wrote: > > Hi, all > > > >We have some new requirements of preferences, I listed > > which of them I known, and think is useful as follows: > > > > 1) for the path of x509 certificate and keys of client > > > >The path of x509 certificate and keys of client is hard > > coded in remote driver. e.g. > > > >/* Defaults for PKI directory. */ > ># define LIBVIRT_PKI_DIR SYSCONFDIR "/pki" > ># define LIBVIRT_CACERT LIBVIRT_PKI_DIR "/CA/cacert.pem" > ># define LIBVIRT_CLIENTKEY LIBVIRT_PKI_DIR "/libvirt/private > > /clientkey.pem" > ># define LIBVIRT_CLIENTCERT LIBVIRT_PKI_DIR "/libvirt/clientcert.pem" > > We can't assume one set of certs/keys is suitable for all > URIs, so making this a preference setting doesn't help. There > needs to be a parameter in the URI to specify a cert/key name > to override the defaults on a per-connection basis As much as I disliked adding long ugly filenames to the URI, I do not see any way around it now. A single client application may need to open two connections with different cert/key pairs, so a single client.conf or environment variables won't cut it. -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Introduce yet another migration version in API.
On Tue, Nov 02, 2010 at 01:08:53PM +, Daniel P. Berrange wrote: > This patch attempts to introduce a version 3 that uses the > improved 5 step sequence > > * Src: Begin > - Generate XML to pass to dst > - Generate optional cookie to pass to dst > > * Dst: Prepare > - Get ready to accept incoming VM > - Generate optional cookie to pass to src > > * Src: Perform > - Start migration and wait for send completion > - Generate optional cookie to pass to dst > > * Dst: Finish > - Wait for recv completion and check status > - Kill off VM if failed, resume if success > - Generate optional cookie to pass to src > > * Src: Confirm > - Kill off VM if success, resume if failed What happens if no confirmation is recieved (destination silently died)? Will there be a timeout (bad idea), or at least a means by which higher level management can cancel migration? Either way, I did not get the suggestion to contact divinity. > +/* > + * If Perform3 indicated an error, or if NULL was returned > + * from Finish3, then the status code tells the source > + * to resume CPUs on the original VM. > + */ > +ret = domain->conn->driver->domainMigrateConfirm3 > +(domain->conn, dname, cookiesrc, cookiesrclen, cookiedst, > cookiedstlen, > + uri, flags, ret >= 0 && domain ? 0 : -1); > +/* XXX is there anything we can do if Confirm3 returns -1. > + * Probably nothing beyond praying > + */ -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 2/2] root_squash saga: virFileOperation may fail with EPERM
Over root-squashing nfs, when virFileOperation() is called as uid==0, it
may fail with EACCES, but also with EPERM, due to
virFileOperationNoFork()'s failed attemp to chown a writable file.
qemudDomainSaveFlag() should expect this case, too.
---
src/qemu/qemu_driver.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index 7204ac8..abd8e9d 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -5402,13 +5402,13 @@ static int qemudDomainSaveFlag(struct qemud_driver
*driver, virDomainPtr dom,
qemudDomainSaveFileOpHook, &hdata,
0)) < 0) {
/* If we failed as root, and the error was permission-denied
- (EACCES), assume it's on a network-connected share where
- root access is restricted (eg, root-squashed NFS). If the
+ (EACCES or EPERM), assume it's on a network-connected share
+ where root access is restricted (eg, root-squashed NFS). If the
qemu user (driver->user) is non-root, just set a flag to
bypass security driver shenanigans, and retry the operation
after doing setuid to qemu user */
-if ((rc != -EACCES) ||
+if (((rc != -EACCES) && (rc != -EPERM)) ||
driver->user == getuid()) {
virReportSystemError(-rc, _("Failed to create domain save file
'%s'"),
path);
--
1.7.2.3
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 1/2] initgroups() in qemudOpenAsUID()
qemudOpenAsUID is intended to open a file with the credentials of a
specified uid. Current implementation fails if the file is accessible to
one of uid's groups but not owned by uid.
This patch replaces the supplementary group list that the child process
inherited from libvirtd with the default group list of uid.
---
src/qemu/qemu_driver.c | 27 ++-
1 files changed, 22 insertions(+), 5 deletions(-)
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index 0ce2d40..7204ac8 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -41,6 +41,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -6353,6 +6354,7 @@ parent_cleanup:
char *buf = NULL;
size_t bufsize = 1024 * 1024;
int bytesread;
+struct passwd pwd, *pwd_result;
/* child doesn't need the read side of the pipe */
close(pipefd[0]);
@@ -6365,6 +6367,26 @@ parent_cleanup:
goto child_cleanup;
}
+if (VIR_ALLOC_N(buf, bufsize) < 0) {
+exit_code = ENOMEM;
+virReportOOMError();
+goto child_cleanup;
+}
+
+exit_code = getpwuid_r(uid, &pwd, buf, bufsize, &pwd_result);
+if (pwd_result == NULL) {
+virReportSystemError(errno,
+ _("cannot getpwuid_r(%d) to read '%s'"),
+ uid, path);
+goto child_cleanup;
+}
+if (initgroups(pwd.pw_name, pwd.pw_gid) != 0) {
+exit_code = errno;
+virReportSystemError(errno,
+ _("cannot initgroups(\"%s\", %d) to read '%s'"),
+ pwd.pw_name, pwd.pw_gid, path);
+goto child_cleanup;
+}
if (setuid(uid) != 0) {
exit_code = errno;
virReportSystemError(errno,
@@ -6379,11 +6401,6 @@ parent_cleanup:
path, uid);
goto child_cleanup;
}
-if (VIR_ALLOC_N(buf, bufsize) < 0) {
-exit_code = ENOMEM;
-virReportOOMError();
-goto child_cleanup;
-}
/* read from fd and write to pipefd[1] until EOF */
do {
--
1.7.2.3
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] initgroups() in qemudOpenAsUID()
On Mon, Oct 18, 2010 at 01:21:05AM -0400, Laine Stump wrote: > On 10/17/2010 04:58 PM, Dan Kenigsberg wrote: > >qemudOpenAsUID is intended to open a file with the credentials of a > >specified uid. Current implementation fails if the file is accessible to > >one of uid's groups but not owned by uid. > > > >This patch replaces the supplementary group list that the child process > >inherited from libvirtd with the default group list of uid. > > > Urr. Yet another twist in this ugly saga. Thanks for figuring it out! The saga continues with another chapter. I've incorporated your comments, and had to use the reentrant getpwuid_r after all. I also bumped into another issue with saving to an already-existing file. -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] initgroups() in qemudOpenAsUID()
qemudOpenAsUID is intended to open a file with the credentials of a
specified uid. Current implementation fails if the file is accessible to
one of uid's groups but not owned by uid.
This patch replaces the supplementary group list that the child process
inherited from libvirtd with the default group list of uid.
---
src/qemu/qemu_driver.c | 16
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index 0ce2d40..a1027d4 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -6353,6 +6353,7 @@ parent_cleanup:
char *buf = NULL;
size_t bufsize = 1024 * 1024;
int bytesread;
+struct passwd *pwd;
/* child doesn't need the read side of the pipe */
close(pipefd[0]);
@@ -6365,6 +6366,21 @@ parent_cleanup:
goto child_cleanup;
}
+/* we can avoid getpwuid_r() in threadless child */
+if ((pwd = getpwuid(uid)) == NULL) {
+exit_code = errno;
+virReportSystemError(errno,
+ _("cannot setuid(%d) to read '%s'"),
+ uid, path);
+goto child_cleanup;
+}
+if (initgroups(pwd->pw_name, pwd->pw_gid) != 0) {
+exit_code = errno;
+virReportSystemError(errno,
+ _("cannot setuid(%d) to read '%s'"),
+ uid, path);
+goto child_cleanup;
+}
if (setuid(uid) != 0) {
exit_code = errno;
virReportSystemError(errno,
--
1.7.2.3
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] python: drop unneccesary conn assignment
Since 554d82a200289938d5639a782a9f12e3e2e968f0, conn is unused. Let's drop it - but keep the signature of the constructor for backward compatibility. --- python/libvirt-override.py |9 - 1 files changed, 0 insertions(+), 9 deletions(-) diff --git a/python/libvirt-override.py b/python/libvirt-override.py index de1af2d..d544a0e 100644 --- a/python/libvirt-override.py +++ b/python/libvirt-override.py @@ -18,15 +18,6 @@ import types class libvirtError(Exception): def __init__(self, defmsg, conn=None, dom=None, net=None, pool=None, vol=None): -if dom is not None: -conn = dom._conn -elif net is not None: -conn = net._conn -elif pool is not None: -conn = pool._conn -elif vol is not None: -conn = vol._conn - # Never call virConnGetLastError(). # virGetLastError() is now thread local err = virGetLastError() -- 1.7.2.1 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] cpu: Add support for CPU vendor
On Tue, Jul 20, 2010 at 11:04:01AM +0200, Jiri Denemark wrote: > > > > > And how about adding policy='disable' attribute, so that I can ask > > > > > virConnectCompareCPU to ignore this particular incompatibility, as I > > > > > do > > > > > with items? > > > > > > > > Just don't use tag in your XML. > > > > > > > > In other words, if you specify in domain XML (or it's cpu > > > > fragment > > > > used by virConnectCompareCPU) and your host CPU is made by different > > > > vendor, > > > > the CPUs won't match. If you don't specify , you don't care > > > > about the > > > > vendor and neither does libvirt. > > > > > > > > I hope it's more clear now. > > > > > > I wanted to (ab)use virConnectCompareCPU to roughly tell a certain cpu > > > model (say athlon) can be emulated on my host. I now see that this is not > > > going to happen, and I'll have to do my own feature set comparison. > > > > I don't see the problem in virConnectCompareCPU() that prevents you using > > it for that ? Checking whether a certain cpu model can be emulated on a > > host is exactly what's virConnectCompareCPU is design todo. We explicitly > > did not want apps to need to do a manual feature set comparison because > > that's just horrible code to get right. > > Yeah exactly, I don't really get what makes you think you can't use > virConnectCompareCPU. > > You can use > > athlon > > to check if athlon model is compatible with host CPU (regardless on vendor). > > If you are not interested in some features (say 3dnowext), you can use > > athlon > > > > And if you only want to run on an AuthenticAMD CPU, you'd use > > athlon > AMD > > Oh, I assumed that the fact the AMD appears in the model definition of "athlon", it is implicit whenever athlon is mentioned. The semantics missing is "don't care about vendor", and the semantics of a missing is "enforce the feature". This is a bit confusing. > > However it all depends on what you mean by "emulated". If you really want to > check if the CPU can be emulated on your machine as in "I have this old > pentium3 box but I want to run a VM which requires the newest Opteron even > though most of its features will be emulated in software" then > virConnectCompareCPU is not currently able to check that for you. But I doubt > you could check this by doing your own feature set comparison since you'd need > to go deep into qemu and check what features it can emulate in software. > > Anyway, if you think virConnectCompareCPU is not doing what it should or if > you have ideas on improving feature set comparison, please share them here. > It's better to improve libvirt than doing all by yourself within your > application. Well, I would like to tell in advance if starting up domain is going to be rejected due to incompatibility between guest cpu and host cpu in the relevant hypervisor (qemu -cpu bla,enforce style). -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] cpu: Add support for CPU vendor
On Mon, Jul 19, 2010 at 02:40:40PM +0200, Jiri Denemark wrote: > > > By specifying element in CPU requirements a guest can be > > > restricted to run only on CPUs by a given vendor. Host CPU vendor is > > > also specified in capabilities XML. > > > > > > The vendor is checked when migrating a guest but it's not forced, i.e., > > > a guest configured without element can be freely migrated. > ... > > > src/cpu/cpu_map.xml |6 + > > > > Why did you add tags to several of the models there? Does qemu > > (-no-kvm) have any problem emulating athlon on an Intel host? > > Honestly, I don't know if qemu has any problems emulating them but it doesn't > really matter. The emelement in cpu_map.xml is used when libvirt > decides what model should be used for describing host CPU. > > > And how about adding policy='disable' attribute, so that I can ask > > virConnectCompareCPU to ignore this particular incompatibility, as I do > > with items? > > Just don't use tag in your XML. > > In other words, if you specify in domain XML (or it's cpu fragment > used by virConnectCompareCPU) and your host CPU is made by different vendor, > the CPUs won't match. If you don't specify , you don't care about the > vendor and neither does libvirt. > > I hope it's more clear now. I wanted to (ab)use virConnectCompareCPU to roughly tell a certain cpu model (say athlon) can be emulated on my host. I now see that this is not going to happen, and I'll have to do my own feature set comparison. Thanks, Dan. -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] cpu: Add support for CPU vendor
On Fri, Jul 02, 2010 at 11:16:22PM +0200, Jiri Denemark wrote: > By specifying element in CPU requirements a guest can be > restricted to run only on CPUs by a given vendor. Host CPU vendor is > also specified in capabilities XML. > > The vendor is checked when migrating a guest but it's not forced, i.e., > a guest configured without element can be freely migrated. > --- > > Sorry for such a big patch but the bulk of it is in cpu/ which is not so easy > to be splitted reasonably. > > > docs/formatcaps.html.in |1 + > docs/formatdomain.html.in |8 + > docs/schemas/capability.rng |5 + > docs/schemas/domain.rng |7 + > src/conf/cpu_conf.c | 14 ++ > src/conf/cpu_conf.h |1 + > src/cpu/cpu.c |9 +- > src/cpu/cpu.h |6 +- > src/cpu/cpu_map.c | 36 -- > src/cpu/cpu_map.h | 20 ++- > src/cpu/cpu_map.xml |6 + Why did you add tags to several of the models there? Does qemu (-no-kvm) have any problem emulating athlon on an Intel host? And how about adding policy='disable' attribute, so that I can ask virConnectCompareCPU to ignore this particular incompatibility, as I do with items? Regards, Dan. -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] cpuCompare: Fix comparison of two host CPUs
On Tue, Jul 13, 2010 at 11:14:13AM +0100, Daniel P. Berrange wrote: > On Tue, Jul 13, 2010 at 12:03:43PM +0200, Jiri Denemark wrote: > > Hi Dan, > > > > > I do not compare CPUs for fun, but rather to know if a guest can be run > > > on a specific host. However, this is not exactly what > > > virConnectCompareCPU gives me: A vmx-enabled host cpu is a superset of > > > itself, but it would not run itself as a guest since we do not have > > > nested vxm yet. Similarly, if we ever have svm-emulation-by-kvm, we > > > could be running svm guests on a vmx host. > > > > > > Is it only me? Or should libvirt expose the more interesting meaning? > > > > Absolutely, that would be just perfect. However, I believe libvirt does the > > best it can. Only hypervisor itself knows that it can emulate some features > > which are not present in host CPU or that some features cannot work in > > guests > > even though host CPU provides them. For such advanced comparison, qemu would > > need to provide a way for libvirt to ask for this stuff. > > Yep, we would need a different API for this, because we would need to be > able to pass in more data than we curently do. eg the machine type, the > emulator binary path, virtualization type (kvm/qemu/xen) etc. It might be > easiest to just have an API that takes the full domain XML instead of just > the CPU XML snipoet Would it make sense to implement this by a VIR_DOMAIN_CHECK_COMPATIBILITY flag to virDomainCreateXML? -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] cpuCompare: Fix comparison of two host CPUs
Jiri, I have an unrelated concern regarding the semantics of comparison of host and guest CPUs. I do not compare CPUs for fun, but rather to know if a guest can be run on a specific host. However, this is not exactly what virConnectCompareCPU gives me: A vmx-enabled host cpu is a superset of itself, but it would not run itself as a guest since we do not have nested vxm yet. Similarly, if we ever have svm-emulation-by-kvm, we could be running svm guests on a vmx host. Is it only me? Or should libvirt expose the more interesting meaning? Dan. On Mon, Jul 12, 2010 at 05:49:36PM +0200, Jiri Denemark wrote: > When a CPU to be compared with host CPU describes a host CPU instead of > a guest CPU, the result is incorrect. This is because instead of > treating additional features in host CPU description as required, they > were treated as if they were mentioned with all possible policies at the > same time. -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] cannot start a qemu64 model on an Intel host
On Wed, Jan 06, 2010 at 10:38:32AM +0100, Jiri Denemark wrote: > > If I specify > > > > > > qemu64 > > > > > > according to the new cpu schema, I get > > error: internal error guest CPU is not compatible with host CPU > > because qemu64 supports svm, and my host does not. > > > > However, the error remains when I explicitly ask to disable svm with > > > > > > I am not sure if this is a bug or an intended feature, but I'd expect > > cpu_disable taken into account when doing > > x86ModelCompare(host_model, cpu_require) > > It is a bug. There's no sense in checking features which will be disabled > anyway. > > Thanks for reporting. Only today was I told of another issue with specifying: qemu64 libvirt's algorithm ends up setting -cpu qemu32,+lm,+nx,+syscall,+cx16,+ssse3,+clflush,+pse36,+mca,+mtrr which is quite different (particularily if you intend to run 64 bit guests), and certainly no what you'd expect with match="expect". Regards, Dan. -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 0/1] enospace disk error policy
On Thu, Apr 08, 2010 at 04:11:32PM -0400, David Allan wrote:
> Dan Kenigsberg requested that we add an option to explicitly request enospace
> as the disk error policy.
>
Well, to be more exact, I asked if leaving it out was intentional ;-)
(But I do think that alowing explicity here is a good idea, thanks)
I do have one issue with error_policy: for qemu-0.12 (with -drive and
id=) libvirt creates a command line such as
qemu-kvm -drive
file=/tmp/1.qcow2,format=qcow2,if=none,werror=stop,id=drive-ide0-0-0
Which qemu does not like ("werror is no supported by this format"). This
error goes away if the "if=none" clause is dropped. I'm not sure if it
is not a qemu bug, though.
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] python binding: openAuth() segfaulting
On Tue, Mar 16, 2010 at 05:50:42PM +0100, Matthias Bolte wrote:
> 2010/3/16 Dan Kenigsberg :
> > I was trying to learn how to use openAuth(uri, auth_cb, flags), and
> > got:
> >
> > Python 2.6.2 (r262:71600, Jan 25 2010, 18:46:47)
> > [GCC 4.4.2 20091222 (Red Hat 4.4.2-20)] on linux2
> > Type "help", "copyright", "credits" or "license" for more information.
> >>>> import libvirt
> >>>> libvirt.openAuth('qemu:///system', lambda x: None, 0)
> > Segmentation fault (core dumped)
> >
> > I guess my lambda expression was not what libvirt expected, but still..
> >
> > Regards,
> >
> > Dan.
> >
>
> Yes, the python bindings lack proper input validation. If you pass
> something unexpected it'll probably segfault.
>
> I've started working on a patch that adds input validation to the
> python bindings.
>
> Until then, see examples/python/esxlist.py in the libvirt codebase for
> the correct usage of the auth parameter in python.
Thanks.
Since I'm using qemu and trying sasl over unix domain, I've changed
uri = "qemu:///system"
and tried esxlist.py out (on Fedora 12, libvirt-0.7.2-1.fc12.x86_64).
I've got the following in /var/log/messages. Any guesses what went wrong?
Mar 21 18:47:01 myhost python: Bad IPLOCALPORT value
Mar 21 18:47:01 myhost python: abrt: detected unhandled Python exception in
/tmp/esxlist.py
Mar 21 18:47:01 myhost abrtd: Directory 'pyhook-1269190021-25439' creation
detected
Mar 21 18:47:01 myhost abrtd: Executable '/tmp/esxlist.py' doesn't belong to
any package
Mar 21 18:47:01 myhost abrtd: Corrupted or bad crash
/var/cache/abrt/pyhook-1269190021-25439 (res
:4), deleting
Mar 21 18:47:01 myhost abrt[25443]: saved python crash dump of pid 25439 to
/var/cache/abrt/pyhoo
k-1269190021-25439.new
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] python binding: openAuth() segfaulting
I was trying to learn how to use openAuth(uri, auth_cb, flags), and
got:
Python 2.6.2 (r262:71600, Jan 25 2010, 18:46:47)
[GCC 4.4.2 20091222 (Red Hat 4.4.2-20)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import libvirt
>>> libvirt.openAuth('qemu:///system', lambda x: None, 0)
Segmentation fault (core dumped)
I guess my lambda expression was not what libvirt expected, but still..
Regards,
Dan.
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [libvirt-users] Regarding SPICE
On Thu, Mar 04, 2010 at 04:21:39PM +0530, anuj rampal wrote: > Hi, > > Thanks a lot for the reply. > > Is it going to be there in the future? > When spice is ready upstream, I have no doubt that libvirt will support it. > And i wanted to confirm one more thing... > KVM on RHEL 5.4 supports SPICE through libvirt? > Because there were some patches regarding " Implement RHEL-5.4 support for > SPICE graphics" Unfortunately these patches never made it to RHEL-5. Maybe some time in the future. -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] docs: add 3 missing spaces
From: danken --- docs/architecture.html.in |2 +- docs/auth.html.in |2 +- docs/logging.html.in |2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/architecture.html.in b/docs/architecture.html.in index 8eb6458..f5cc520 100644 --- a/docs/architecture.html.in +++ b/docs/architecture.html.in @@ -83,7 +83,7 @@ drivers present in driver.h: xen_internal: provide the implementation of the functions possible via direct hypervisor access proxy_internal: provide read-only Xen access via a proxy, the proxy code -is in the proxy/directory. +is in the proxy/ directory. xm_internal: provide support for Xen defined but not running domains. qemu_internal: implement the driver functions for QEmu and diff --git a/docs/auth.html.in b/docs/auth.html.in index 3ca40c3..ab6c3e9 100644 --- a/docs/auth.html.in +++ b/docs/auth.html.in @@ -72,7 +72,7 @@ available. The two libvirt daemon actions available are named org.libvirt. for the RO socket, and org.libvirt.unix.manage for the RW socket. -As an example, to allow a user fredfull access to the RW socket, +As an example, to allow a user fred full access to the RW socket, while requiring joe to authenticate with the admin password, would require adding the following snippet to PolicyKit.conf. diff --git a/docs/logging.html.in b/docs/logging.html.in index 63a0b05..f4a5878 100644 --- a/docs/logging.html.in +++ b/docs/logging.html.in @@ -96,7 +96,7 @@ x:stderr output goes to stderr x:syslog:name use syslog for the output and use the given name as the ident - x:file:file_pathoutput to a file, with the given + x:file:file_path output to a file, with the given filepath In all cases the x prefix is the minimal level, acting as a filter: -- 1.6.6 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 0/12] Improve security driver handling & QEMU DAC management
On Tue, Jan 26, 2010 at 12:56:00PM +, Daniel P. Berrange wrote: > On Tue, Jan 26, 2010 at 02:28:45PM +0200, Dan Kenigsberg wrote: > > On Tue, Jan 26, 2010 at 10:23:01AM +, Daniel P. Berrange wrote: > > > On Tue, Jan 26, 2010 at 12:06:58PM +0200, Dan Kenigsberg wrote: > > > > On Wed, Jan 20, 2010 at 03:14:57PM +, Daniel P. Berrange wrote: > > > > > This patch series does some work on te security drivers, and the QEMU > > > > > code > > > > > for managing DAC permissions on files. > > > > > > > > > > The core goal is to turn the QEMU driver DAC file management code > > > > > into a > > > > > security driver. Instead of QEMU calling into the SELinux/AppArmour > > > > > drivers > > > > > directly, a stacked driver module is introduced. This delegates all > > > > > operations > > > > > to first the QEMU DAC driver, and then the main SELinux/AppArmour > > > > > driver. > > > > > The end result is that all the permissions management code is removed > > > > > from > > > > > the QEMU driver, and we're left with just simple security driver > > > > > calls. > > > > > > > > > > In the process of this a number of flaws in the current hotplug code > > > > > were > > > > > found, and code was generally tidied up with a view to making it > > > > > easier to > > > > > manage. > > > > > > > > > > Finally, we add the ability to turn off the QEMU DAC file managment > > > > > code, > > > > > and also deal gracefully with failures to change ownership (eg on NFS > > > > > with > > > > > root squash, or readonly FS). > > > > > > > > hmmm, there's another problem which this patch set does not address: > > > > error : virStorageFileGetMetadata:415 : cannot open file > > > > '/deep/into/my/root/squashing/export': Permission denied > > > > > > > > With dynamic_ownership = 0, libvirt down not mess with chown, but it now > > > > assumes that it can read disk images. > > > > > > That is a not unreasonable assumption. The model we want to support is one > > > where > > > > > > - App uses virStoragePool APIs to setup the NFS mount point on the host > > > - App uses virStorageVol APIs to create the new volume with correct > > >ownership at time of creation > > > - libvirt starts the guest, without needing chown() due to step 2 > > >getting ownership correct at time of creation. > > > > > > If libvirt can't read the directories leading upto the image, then it > > > would never have been able to create the volume in the first place. The > > > patchs we have done have aimed at avoiding root squash problems which > > > prevent chmod/chown of files between root & non-root. We still assume > > > that we can read files / browse directories. > > > > Understood. But if I am handling storage myself, I have a regression > > when I switch to libvirt from the sordid art of playing with qemu > > directly. I don't want to make my repository world-readable, and I don't > > want (yet) to use libvirt storage API. > > > > Do I have a third option? > > virStorageFileGetMetadata() is used to determine if the disk configured > for a guest has a backing file (eg qcow linked images). This is called > from the DAC driver to setup ownership, and from the SELinux driver to > setup labelling. You say you've already disabled the DAC driver ownership > so it shouldn't be hitting it there. Thus I assume it must the SELinux > driver that's causing the error. > > > Note that before this patchset, I could apply a patch disabling chown's > > and I managed to start domains over root squashing nfs. > > I'm surprised if that's true, because I don't believe my patches changed > this behaviour of the SELinux driver - it was always calling into the > virStorageFileGetMetadata() method to determine backing store, so should > always have hit the issue you describe Ok I was probably too hasty to blame this patchset, after all, I tested it earlier on a different machine with a different os and a different storage export. However my question still stands: what can I do to make this work when the storage is not readable by root? -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 0/12] Improve security driver handling & QEMU DAC management
On Tue, Jan 26, 2010 at 10:23:01AM +, Daniel P. Berrange wrote: > On Tue, Jan 26, 2010 at 12:06:58PM +0200, Dan Kenigsberg wrote: > > On Wed, Jan 20, 2010 at 03:14:57PM +, Daniel P. Berrange wrote: > > > This patch series does some work on te security drivers, and the QEMU code > > > for managing DAC permissions on files. > > > > > > The core goal is to turn the QEMU driver DAC file management code into a > > > security driver. Instead of QEMU calling into the SELinux/AppArmour > > > drivers > > > directly, a stacked driver module is introduced. This delegates all > > > operations > > > to first the QEMU DAC driver, and then the main SELinux/AppArmour driver. > > > The end result is that all the permissions management code is removed > > > from > > > the QEMU driver, and we're left with just simple security driver calls. > > > > > > In the process of this a number of flaws in the current hotplug code were > > > found, and code was generally tidied up with a view to making it easier to > > > manage. > > > > > > Finally, we add the ability to turn off the QEMU DAC file managment code, > > > and also deal gracefully with failures to change ownership (eg on NFS with > > > root squash, or readonly FS). > > > > hmmm, there's another problem which this patch set does not address: > > error : virStorageFileGetMetadata:415 : cannot open file > > '/deep/into/my/root/squashing/export': Permission denied > > > > With dynamic_ownership = 0, libvirt down not mess with chown, but it now > > assumes that it can read disk images. > > That is a not unreasonable assumption. The model we want to support is one > where > > - App uses virStoragePool APIs to setup the NFS mount point on the host > - App uses virStorageVol APIs to create the new volume with correct >ownership at time of creation > - libvirt starts the guest, without needing chown() due to step 2 >getting ownership correct at time of creation. > > If libvirt can't read the directories leading upto the image, then it > would never have been able to create the volume in the first place. The > patchs we have done have aimed at avoiding root squash problems which > prevent chmod/chown of files between root & non-root. We still assume > that we can read files / browse directories. Understood. But if I am handling storage myself, I have a regression when I switch to libvirt from the sordid art of playing with qemu directly. I don't want to make my repository world-readable, and I don't want (yet) to use libvirt storage API. Do I have a third option? Note that before this patchset, I could apply a patch disabling chown's and I managed to start domains over root squashing nfs. Regards, Dan. -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 0/12] Improve security driver handling & QEMU DAC management
On Wed, Jan 20, 2010 at 03:14:57PM +, Daniel P. Berrange wrote: > This patch series does some work on te security drivers, and the QEMU code > for managing DAC permissions on files. > > The core goal is to turn the QEMU driver DAC file management code into a > security driver. Instead of QEMU calling into the SELinux/AppArmour drivers > directly, a stacked driver module is introduced. This delegates all operations > to first the QEMU DAC driver, and then the main SELinux/AppArmour driver. > The end result is that all the permissions management code is removed from > the QEMU driver, and we're left with just simple security driver calls. > > In the process of this a number of flaws in the current hotplug code were > found, and code was generally tidied up with a view to making it easier to > manage. > > Finally, we add the ability to turn off the QEMU DAC file managment code, > and also deal gracefully with failures to change ownership (eg on NFS with > root squash, or readonly FS). hmmm, there's another problem which this patch set does not address: error : virStorageFileGetMetadata:415 : cannot open file '/deep/into/my/root/squashing/export': Permission denied With dynamic_ownership = 0, libvirt down not mess with chown, but it now assumes that it can read disk images. Regrards, Dan. -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 0/12] Improve security driver handling & QEMU DAC management
On Wed, Jan 20, 2010 at 03:14:57PM +, Daniel P. Berrange wrote: > This patch series does some work on te security drivers, and the QEMU code > for managing DAC permissions on files. > > The core goal is to turn the QEMU driver DAC file management code into a > security driver. Instead of QEMU calling into the SELinux/AppArmour drivers > directly, a stacked driver module is introduced. This delegates all operations > to first the QEMU DAC driver, and then the main SELinux/AppArmour driver. > The end result is that all the permissions management code is removed from > the QEMU driver, and we're left with just simple security driver calls. > > In the process of this a number of flaws in the current hotplug code were > found, and code was generally tidied up with a view to making it easier to > manage. > > Finally, we add the ability to turn off the QEMU DAC file managment code, > and also deal gracefully with failures to change ownership (eg on NFS with > root squash, or readonly FS). Thanks for this series. However, it seems that we still have a problem when trying to save domain to a root-squashing nfs export. When using qemu directly, as a user with write permissions to that export, there is no problem. When using libvirt, libvirt tries to write its own state to the target file. I would not want to pre-create the target file as world redable. How about performing open(path, O_CREAT|O_TRUNC|O_WRONLY, S_IRUSR|S_IWUSR)) with the euid of the qemu process? Dan. -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] allow (only) surrounding whitespace in uuid
On Thu, Jan 21, 2010 at 03:33:21PM +0100, Daniel Veillard wrote: > On Tue, Jan 05, 2010 at 02:51:06PM +0200, Dan Kenigsberg wrote: > > Please consider something along these lines. Without it, pretty-printed > > domxml is rejected due to the whitespace before uuid, and long long > > string of hexadecimal digits is accepted. > > --- > > Yes that looks fine to me and testing for NUL termination sound > important, ACK, > >pushed, thanks ! Thank you. Though since I've sent that, I noticed that surrounding whitespace is a more general problem of xml text nodes, such as the element. Should libvirt consider any surrounding whitespace as insignificant? What's usually done in the xml world? Dan. -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] allow (only) surrounding whitespace in uuid
Please consider something along these lines. Without it, pretty-printed
domxml is rejected due to the whitespace before uuid, and long long
string of hexadecimal digits is accepted.
---
src/util/uuid.c | 12 +++-
1 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/src/util/uuid.c b/src/util/uuid.c
index 002a64d..0f2ca96 100644
--- a/src/util/uuid.c
+++ b/src/util/uuid.c
@@ -145,9 +145,13 @@ virUUIDParse(const char *uuidstr, unsigned char *uuid) {
/*
* do a liberal scan allowing '-' and ' ' anywhere between character
- * pairs as long as there is 32 of them in the end.
+ * pairs, and surrounding whitespace, as long as there are exactly
+ * 32 hexadecimal digits the end.
*/
cur = uuidstr;
+while (c_isspace(*cur))
+cur++;
+
for (i = 0;i < VIR_UUID_BUFLEN;) {
uuid[i] = 0;
if (*cur == 0)
@@ -170,6 +174,12 @@ virUUIDParse(const char *uuidstr, unsigned char *uuid) {
cur++;
}
+while (*cur) {
+if (!c_isspace(*cur))
+goto error;
+cur++;
+}
+
return 0;
error:
--
1.6.5.2
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] cannot start a qemu64 model on an Intel host
If I specify qemu64 according to the new cpu schema, I get error: internal error guest CPU is not compatible with host CPU because qemu64 supports svm, and my host does not. However, the error remains when I explicitly ask to disable svm with I am not sure if this is a bug or an intended feature, but I'd expect cpu_disable taken into account when doing x86ModelCompare(host_model, cpu_require) Regards, Dan. -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] (v2) avoid chowning domain devices if higer-level mgmt does it for us
Only now did I notice another problem with root_squasing nfs, unrelated to chown and unadressed by my patch: qemudDomainSave tries to create the target image file and write into it as root. How reasonable would it be to seteuid() to qemu user before doing so? -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] questions on build qemu driver with non-root
On Fri, Nov 27, 2009 at 12:33:49PM -0800, Shi Jin wrote: > Hi there, > > I have been successful in building the latest libvirt code from the git > repository. The options I used to build is > > ./autogen.sh --prefix=/usr --sysconfdir=/etc --localstatedir=/var > --without-xen --with-qemu --with-qemu-user=oneadmin > --with-qemu-group=oneadmin --without-uml --without-vbox --without-openvz > --without-lxc > > Please note that I have specified qemu user and group to be non-root. > > So far the libvirtd service and virsh both seem to work fine but I have a few > issues > 1. Before running "virsh create", the image belongs to user oneadmin. During > the run, it still does. But the as soon as I shutdown/destroy the instance, > the image ownership changes to > -rw-rw—— 1 root root > I don't understand why. Is this a bug? Just the other day we agreed that it needs to be fixed https://www.redhat.com/archives/libvir-list/2009-November/msg00723.html -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Problem in handling fast prints from QEMU to stderr
On Thu, Nov 26, 2009 at 11:51:48AM +, Daniel P. Berrange wrote: > On Wed, Nov 25, 2009 at 06:49:24PM +0200, Saul Tamari wrote: > > Hi, > > > > I think I spotted a bug in the way libvirtd handles stderr output from QEMU > > VMs. > > > > When starting a VM and QEMU outputs too much output data to stderr > > (during a given time period), libvirtd will fail and report the > > following error to /var/log/messages: > > libvirtd: 13:44:40.695: error : internal error Out of space while > > reading console log output > > > > I looked at the libvirt code a bit and it seems like the > > stderr-handling code (I think its in qemudReadLogOutput()) is > > time-dependent and if a 4K buffer overflows it will stop running this > > VM. > > As a workaround I added some usleep(25) near the fprintf() calls > > (inside QEMU) and I now manage to get the VM running. > > > > Is this the way libvirtd is supposed to behave? > > We only look at stdout to find the path for the PTY based char devices. > This is the first thing QEMU prints out to stderr when operating normally > and easily fits in 4K. So the real question is why is your QEMU binary > spewing so much junk to stdout/stderr before the PTY paths ? Is there > anything of interest in /var/log/libvirt/qemu/$GUESTNAME.log Could it be related to the Nov 26 06:59:30 white-vdsa libvirtd: 06:59:30.456: error : qemudReadLogOutput:1185 : internal error Timed out while reading console log output Nov 26 06:59:30 white-vdsa libvirtd: 06:59:30.456: error : qemudWaitForMonitor:1304 : internal error unable to start guest: I'm seeing once in a while? I, too, have non-standard debug info spewing from qemu. -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Fix threading problems in python bindings
On Wed, Nov 25, 2009 at 12:06:03PM +, Daniel P. Berrange wrote: > * libvirt-override.c: Add many missing calls to allow threading > when entering C code, otherwise python blocks & then deadlocks > when we have an async event to dispatch back into python code Thanks, but I am still experiencing deadlocks when I run more than one domain. Thread 3 (Thread 0x52022940 (LWP 29704)): #0 0x003cc1c0c9b1 in sem_wait () from /lib64/libpthread.so.0 #1 0x003cc24b8148 in PyThread_acquire_lock (lock=, waitflag=) at Python/thread_pthread.h:313 #2 0x003cc2496084 in PyEval_RestoreThread (tstate=) at Python/ceval.c:305 #3 0x003cc24b1eac in PyGILState_Ensure () at Python/pystate.c:508 #4 0x2ae384d41605 in libvirt_virEventUpdateHandleFunc (watch=2, event=0) at libvirt-override.c:2279 #5 0x2ae384fbd016 in remoteIO (conn=0xf57b560, priv=0x2ad7a010, flags=0, thiscall=0x2c0008e0) at remote/remote_driver.c:8437 #6 0x2ae384fbdbab in call (conn=0xf57b560, priv=0x2ad7a010, flags=0, proc_nr=, args_filter=0x2ae384fd0af0 , args=0x52020120 "\220ZX\017", ret_filter=0x2ae384fcdfe0 , ret=0x520200e0 "") at remote/remote_driver.c:8508 #7 0x2ae384fc084b in remoteDomainInterfaceStats (domain=0xf57fdc0, path=0xf630e34 "vnet1", stats=0x520201a0) at remote/remote_driver.c:3345 #8 0x2ae384fafd82 in virDomainInterfaceStats (dom=0xf57fdc0, path=0xf630e34 "vnet1", stats=0x52020210, size=64) at libvirt.c:4083 #9 0x2ae384d433e7 in libvirt_virDomainInterfaceStats ( self=, args=) at libvirt-override.c:103 #10 0x003cc24950ba in PyEval_EvalFrame (f=) at Python/ceval.c:3563 #11 0x003cc2495fe5 in PyEval_EvalCodeEx (co=, globals=, locals=, args=, argcount=, kws=, kwcount=, defs=, defcount=, closure=) at Python/ceval.c:2736 #12 0x003cc244c45a in function_call (func=, arg=, kw=) at Objects/funcobject.c:548 #13 0x003cc24360f0 in PyObject_Call (func=, arg=, kw=) at Objects/abstract.c:1795 #14 0x003cc249352c in PyEval_EvalFrame (f=) at Python/ceval.c:3840 #15 0x003cc2495fe5 in PyEval_EvalCodeEx (co=, globals=, locals=, args=, argcount=, kws=, kwcount=, defs=, defcount=, closure=) at Python/ceval.c:2736 #16 0x003cc249473f in PyEval_EvalFrame (f=) at Python/ceval.c:3656 #17 0x003cc2495fe5 in PyEval_EvalCodeEx (co=, globals=, locals=, args=, argcount=, kws=, kwcount=, defs=, defcount=, closure=) at Python/ceval.c:2736 #18 0x003cc244c367 in function_call (func=, arg=, kw=) at Objects/funcobject.c:548 #19 0x003cc24360f0 in PyObject_Call (func=, arg=, kw=) at Objects/abstract.c:1795 #20 0x003cc243c1ef in instancemethod_call (func=, arg=, kw=) at Objects/classobject.c:2447 #21 0x003cc24360f0 in PyObject_Call (func=, arg=, kw=) at Objects/abstract.c:1795 #22 0x003cc248fc3d in PyEval_CallObjectWithKeywords ( func=, arg=, kw=) at Python/ceval.c:3430 #23 0x003cc243fc10 in PyInstance_New (klass=, arg=, kw=) at Objects/classobject.c:575 #24 0x003cc24360f0 in PyObject_Call (func=, arg=, kw=) at Objects/abstract.c:1795 #25 0x003cc24928ce in PyEval_EvalFrame (f=) at Python/ceval.c:3771 #26 0x003cc2495fe5 in PyEval_EvalCodeEx (co=, globals=, locals=, args=, argcount=, kws=, kwcount=, defs=, defcount=, closure=) at Python/ceval.c:2736 #27 0x003cc244c367 in function_call (func=, arg=, kw=) at Objects/funcobject.c:548 #28 0x003cc24360f0 in PyObject_Call (func=, arg=, kw=) at Objects/abstract.c:1795 #29 0x003cc243c1ef in instancemethod_call (func=, arg=, kw=) at Objects/classobject.c:2447 #30 0x003cc24360f0 in PyObject_Call (func=, arg=, kw=) at Objects/abstract.c:1795 #31 0x003cc248fc3d in PyEval_CallObjectWithKeywords ( func=, arg=, kw=) at Python/ceval.c:3430 #32 0x003cc243fc10 in PyInstance_New (klass=, arg=, kw=) at Objects/classobject.c:575 #33 0x003cc24360f0 in PyObject_Call (func=, arg=, kw=) at Objects/abstract.c:1795 #34 0x003cc24928ce in PyEval_EvalFrame (f=) at Python/ceval.c:3771 #35 0x003cc2494b66 in PyEval_EvalFrame (f=) at Python/ceval.c:3645 #36 0x003cc2494b66 in PyEval_EvalFrame (f=) at Python/ceval.c:3645 #37 0x003cc2495fe5 in PyEval_EvalCodeEx (co=, globals=, locals=, args=, argcount=, kws=, kwcount=, defs=, defcount=, closure=) at Python/ceval.c:2736 #38 0x003cc244c367 in function_call (func=, arg=, kw=) at Objects/funcobject.c:548 #39 0x003cc24360f0 in PyObject_Call (func=, arg=, kw=) at Objects/abstract.c:1795 #40 0x003cc243c1ef in instancemethod_call (func=, arg=, kw=) at Objects/classobject.c:2447 #41 0x003cc24360f0 in PyObject_Call (func=, arg=, kw=) at Objects/abstract.c:1795
Re: [libvirt] [PATCH] (v2) avoid chowning domain devices if higer-level mgmt does it for us
On Wed, Nov 25, 2009 at 10:31:03AM +0100, Daniel Veillard wrote:
> On Wed, Nov 25, 2009 at 09:27:13AM +0200, Dan Kenigsberg wrote:
> > this is particularily important if said device is a file sitting on a
> > root_squashing nfs export.
> >
> > my previous attempt for a patch missed 3 chowns that should be avoided.
> > ---
> > src/qemu/qemu.conf |4
> > src/qemu/qemu_conf.c |3 +++
> > src/qemu/qemu_conf.h |1 +
> > src/qemu/qemu_driver.c |8
> > 4 files changed, 12 insertions(+), 4 deletions(-)
> >
> > diff --git a/src/qemu/qemu.conf b/src/qemu/qemu.conf
> > index bca858a..892a50b 100644
> > --- a/src/qemu/qemu.conf
> > +++ b/src/qemu/qemu.conf
> > @@ -96,6 +96,10 @@
> > # The group ID for QEMU processes run by the system instance
> > #group = "root"
> >
> > +# should libvirt assume that devices are accessible to the above
> > user:group.
> > +# by default, libvirt tries to chown devices before starting up a domain
> > and
> > +# restore ownership to root when domain comes down.
> > +#assume_devices_accessible = 0
> >
> > # What cgroup controllers to make use of with QEMU guests
> > #
> > diff --git a/src/qemu/qemu_conf.c b/src/qemu/qemu_conf.c
> > index b1b9e5f..520a395 100644
> > --- a/src/qemu/qemu_conf.c
> > +++ b/src/qemu/qemu_conf.c
> > @@ -232,6 +232,9 @@ int qemudLoadDriverConfig(struct qemud_driver *driver,
> > return -1;
> > }
> >
> > +p = virConfGetValue (conf, "assume_devices_accessible");
> > +CHECK_TYPE ("assume_devices_accessible", VIR_CONF_LONG);
> > +if (p) driver->avoid_dev_chown = p->l;
>
> an explicit initialization of the field would be better if p is NULL.
>
> > if (virGetGroupID(NULL, group, &driver->group) < 0) {
> > VIR_FREE(group);
> > diff --git a/src/qemu/qemu_conf.h b/src/qemu/qemu_conf.h
> > index 675c636..3a9da73 100644
> > --- a/src/qemu/qemu_conf.h
> > +++ b/src/qemu/qemu_conf.h
> > @@ -87,6 +87,7 @@ struct qemud_driver {
> >
> > uid_t user;
> > gid_t group;
> > +int avoid_dev_chown;
> >
> > unsigned int qemuVersion;
> > int nextvmid;
> > diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
> > index 2f273eb..5f02aa2 100644
> > --- a/src/qemu/qemu_driver.c
> > +++ b/src/qemu/qemu_driver.c
> > @@ -1968,7 +1968,7 @@ static int qemuDomainSetDeviceOwnership(virConnectPtr
> > conn,
> > uid_t uid;
> > gid_t gid;
> >
> > -if (!driver->privileged)
> > +if (!driver->privileged || driver->avoid_dev_chown)
> > return 0;
> >
> > /* short circuit case of root:root */
> > @@ -2002,7 +2002,7 @@ static int
> > qemuDomainSetAllDeviceOwnership(virConnectPtr conn,
> > uid_t uid;
> > gid_t gid;
> >
> > -if (!driver->privileged)
> > +if (!driver->privileged || driver->avoid_dev_chown)
> > return 0;
> >
> > /* short circuit case of root:root */
> > @@ -3438,7 +3438,7 @@ static int qemudDomainSave(virDomainPtr dom,
> > }
> > fd = -1;
> >
> > -if (driver->privileged &&
> > +if (driver->privileged && !driver->avoid_dev_chown &&
> > chown(path, driver->user, driver->group) < 0) {
> > virReportSystemError(NULL, errno,
> > _("unable to set ownership of '%s' to user
> > %d:%d"),
> > @@ -3473,7 +3473,7 @@ static int qemudDomainSave(virDomainPtr dom,
> > if (rc < 0)
> > goto endjob;
> >
> > -if (driver->privileged &&
> > +if (driver->privileged && !driver->avoid_dev_chown &&
> > chown(path, 0, 0) < 0) {
> > virReportSystemError(NULL, errno,
> > _("unable to set ownership of '%s' to user
> > %d:%d"),
>
> The core question is having this as another manual user tweak, it always
> makes me a bit uncomfortable if proper working of software requires manually
> editing a config file. If we really need this kind of options for proper
> operations in specific conditions can we make sure it can be set via
> APIs too ? I don't think we should expose something as generic as the
> internal Conf APIs, but these runtime option in src/qemu/qemu.conf
> start to accumulat
[libvirt] [PATCH] (v2) avoid chowning domain devices if higer-level mgmt does it for us
this is particularily important if said device is a file sitting on a
root_squashing nfs export.
my previous attempt for a patch missed 3 chowns that should be avoided.
---
src/qemu/qemu.conf |4
src/qemu/qemu_conf.c |3 +++
src/qemu/qemu_conf.h |1 +
src/qemu/qemu_driver.c |8
4 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/src/qemu/qemu.conf b/src/qemu/qemu.conf
index bca858a..892a50b 100644
--- a/src/qemu/qemu.conf
+++ b/src/qemu/qemu.conf
@@ -96,6 +96,10 @@
# The group ID for QEMU processes run by the system instance
#group = "root"
+# should libvirt assume that devices are accessible to the above user:group.
+# by default, libvirt tries to chown devices before starting up a domain and
+# restore ownership to root when domain comes down.
+#assume_devices_accessible = 0
# What cgroup controllers to make use of with QEMU guests
#
diff --git a/src/qemu/qemu_conf.c b/src/qemu/qemu_conf.c
index b1b9e5f..520a395 100644
--- a/src/qemu/qemu_conf.c
+++ b/src/qemu/qemu_conf.c
@@ -232,6 +232,9 @@ int qemudLoadDriverConfig(struct qemud_driver *driver,
return -1;
}
+p = virConfGetValue (conf, "assume_devices_accessible");
+CHECK_TYPE ("assume_devices_accessible", VIR_CONF_LONG);
+if (p) driver->avoid_dev_chown = p->l;
if (virGetGroupID(NULL, group, &driver->group) < 0) {
VIR_FREE(group);
diff --git a/src/qemu/qemu_conf.h b/src/qemu/qemu_conf.h
index 675c636..3a9da73 100644
--- a/src/qemu/qemu_conf.h
+++ b/src/qemu/qemu_conf.h
@@ -87,6 +87,7 @@ struct qemud_driver {
uid_t user;
gid_t group;
+int avoid_dev_chown;
unsigned int qemuVersion;
int nextvmid;
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index 2f273eb..5f02aa2 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -1968,7 +1968,7 @@ static int qemuDomainSetDeviceOwnership(virConnectPtr
conn,
uid_t uid;
gid_t gid;
-if (!driver->privileged)
+if (!driver->privileged || driver->avoid_dev_chown)
return 0;
/* short circuit case of root:root */
@@ -2002,7 +2002,7 @@ static int qemuDomainSetAllDeviceOwnership(virConnectPtr
conn,
uid_t uid;
gid_t gid;
-if (!driver->privileged)
+if (!driver->privileged || driver->avoid_dev_chown)
return 0;
/* short circuit case of root:root */
@@ -3438,7 +3438,7 @@ static int qemudDomainSave(virDomainPtr dom,
}
fd = -1;
-if (driver->privileged &&
+if (driver->privileged && !driver->avoid_dev_chown &&
chown(path, driver->user, driver->group) < 0) {
virReportSystemError(NULL, errno,
_("unable to set ownership of '%s' to user
%d:%d"),
@@ -3473,7 +3473,7 @@ static int qemudDomainSave(virDomainPtr dom,
if (rc < 0)
goto endjob;
-if (driver->privileged &&
+if (driver->privileged && !driver->avoid_dev_chown &&
chown(path, 0, 0) < 0) {
virReportSystemError(NULL, errno,
_("unable to set ownership of '%s' to user
%d:%d"),
--
1.6.5.2
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] avoid chowning domain devices if higer-level mgmt does it for us
this is particularily important if said device is a file sitting on a
root_squashing nfs export.
---
src/qemu/qemu.conf |4
src/qemu/qemu_conf.c |3 +++
src/qemu/qemu_conf.h |1 +
src/qemu/qemu_driver.c |2 +-
4 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/src/qemu/qemu.conf b/src/qemu/qemu.conf
index bca858a..892a50b 100644
--- a/src/qemu/qemu.conf
+++ b/src/qemu/qemu.conf
@@ -96,6 +96,10 @@
# The group ID for QEMU processes run by the system instance
#group = "root"
+# should libvirt assume that devices are accessible to the above user:group.
+# by default, libvirt tries to chown devices before starting up a domain and
+# restore ownership to root when domain comes down.
+#assume_devices_accessible = 0
# What cgroup controllers to make use of with QEMU guests
#
diff --git a/src/qemu/qemu_conf.c b/src/qemu/qemu_conf.c
index b1b9e5f..520a395 100644
--- a/src/qemu/qemu_conf.c
+++ b/src/qemu/qemu_conf.c
@@ -232,6 +232,9 @@ int qemudLoadDriverConfig(struct qemud_driver *driver,
return -1;
}
+p = virConfGetValue (conf, "assume_devices_accessible");
+CHECK_TYPE ("assume_devices_accessible", VIR_CONF_LONG);
+if (p) driver->avoid_dev_chown = p->l;
if (virGetGroupID(NULL, group, &driver->group) < 0) {
VIR_FREE(group);
diff --git a/src/qemu/qemu_conf.h b/src/qemu/qemu_conf.h
index 675c636..3a9da73 100644
--- a/src/qemu/qemu_conf.h
+++ b/src/qemu/qemu_conf.h
@@ -87,6 +87,7 @@ struct qemud_driver {
uid_t user;
gid_t group;
+int avoid_dev_chown;
unsigned int qemuVersion;
int nextvmid;
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index 2f273eb..4c5de80 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -1968,7 +1968,7 @@ static int qemuDomainSetDeviceOwnership(virConnectPtr
conn,
uid_t uid;
gid_t gid;
-if (!driver->privileged)
+if (!driver->privileged || driver->avoid_dev_chown)
return 0;
/* short circuit case of root:root */
--
1.6.5.2
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] fix html validation
--- docs/news.html.in |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/news.html.in b/docs/news.html.in index d69348c..83f0461 100644 --- a/docs/news.html.in +++ b/docs/news.html.in @@ -21,11 +21,11 @@ and check the ChangeLog to gauge progress. Fix typo in error message (Matthew Booth) esx: Add documentation to the website (Matthias Bolte) AppArmor updates of examples (Jamie Strandboge) - Add documentation for domain element (Matthew Booth) + Add documentation for <channel> domain element (Matthew Booth) Separate character device doc guest and host parts (Matthew Booth) Add a Python example that lists active ESX domains (Matthias Bolte) LXC fix wrong or out-of-date function descriptions (Ryota Ozaki) - docs: property is 'offset', not 'sync' (Cole Robinson) + docs: <clock> property is 'offset', not 'sync' (Cole Robinson) Update the documentation for virDomainMigrateToURI (Chris Lalancette) fix virDomainMigrateToURI doc (Dan Kenigsberg) @@ -118,7 +118,7 @@ and check the ChangeLog to gauge progress. test: Add testDomainShutdownState helper (Cole Robinson) Properly convert port numbers to/from network byte order (Matthew Booth) phyp add create() and destroy() support (Eduardo Otubo) - Support for in domain and QEmu backend (Matthew Booth) + Support for <channel> in domain and QEmu backend (Matthew Booth) Detect availability of QEMU -chardev CLI option (Matthew Booth) Allow character devices to have different target types (Matthew Booth) LXC allow container to have ethN interfaces (Ryota Ozaki) -- 1.6.5.2 -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] make qemu monitor timeout configurable
we've experience cases where waiting 30 seconds for a qemu monitor to
finish was not enough (slow and busy server with slow storage). that was
with managing qemu processes directly, btw, not with libvirt. however
those case where not common. how about making the timeout configurable
on-site?
---
src/qemu/qemu.conf |5 +
src/qemu/qemu_conf.c | 10 ++
src/qemu/qemu_conf.h |2 ++
src/qemu/qemu_driver.c | 29 ++---
4 files changed, 31 insertions(+), 15 deletions(-)
diff --git a/src/qemu/qemu.conf b/src/qemu/qemu.conf
index 2129bae..bca858a 100644
--- a/src/qemu/qemu.conf
+++ b/src/qemu/qemu.conf
@@ -157,3 +157,8 @@
# This currently requires ebtables to be installed.
#
# mac_filter = 1
+
+# job_wait_time specifies how many seconds should a qemu monitor query wait for
+# the monitor mutex.
+#
+# job_wait_time = 30
diff --git a/src/qemu/qemu_conf.c b/src/qemu/qemu_conf.c
index 225a760..bcbe80d 100644
--- a/src/qemu/qemu_conf.c
+++ b/src/qemu/qemu_conf.c
@@ -340,6 +340,16 @@ int qemudLoadDriverConfig(struct qemud_driver *driver,
}
}
+p = virConfGetValue (conf, "job_wait_time");
+CHECK_TYPE ("job_wait_time", VIR_CONF_LONG);
+if (p && p->l) {
+driver->job_wait_time = 1000ull * p->l;
+} else {
+driver->job_wait_time = 1000ull * 30;
+}
+if (driver->job_wait_time <= 0)
+driver->job_wait_time = 1;
+
virConfFree (conf);
return 0;
}
diff --git a/src/qemu/qemu_conf.h b/src/qemu/qemu_conf.h
index 1931aef..0d816e2 100644
--- a/src/qemu/qemu_conf.h
+++ b/src/qemu/qemu_conf.h
@@ -134,6 +134,8 @@ struct qemud_driver {
char *saveImageFormat;
pciDeviceList *activePciHostdevs;
+
+int job_wait_time;
};
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index a4a87ac..2f273eb 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -160,11 +160,10 @@ static void qemuDomainObjPrivateFree(void *data)
* successful calls must be followed by EndJob eventually
*/
-/* Give up waiting for mutex after 30 seconds */
-#define QEMU_JOB_WAIT_TIME (1000ull * 30)
-
-static int qemuDomainObjBeginJob(virDomainObjPtr obj) ATTRIBUTE_RETURN_CHECK;
-static int qemuDomainObjBeginJob(virDomainObjPtr obj)
+static int qemuDomainObjBeginJob(struct qemud_driver *driver,
+ virDomainObjPtr obj) ATTRIBUTE_RETURN_CHECK;
+static int qemuDomainObjBeginJob(struct qemud_driver *driver,
+ virDomainObjPtr obj)
{
qemuDomainObjPrivatePtr priv = obj->privateData;
struct timeval now;
@@ -176,7 +175,7 @@ static int qemuDomainObjBeginJob(virDomainObjPtr obj)
return -1;
}
then = (now.tv_sec * 1000ull) + (now.tv_usec / 1000);
-then += QEMU_JOB_WAIT_TIME;
+then += driver->job_wait_time;
virDomainObjRef(obj);
@@ -218,7 +217,7 @@ static int qemuDomainObjBeginJobWithDriver(struct
qemud_driver *driver,
return -1;
}
then = (now.tv_sec * 1000ull) + (now.tv_usec / 1000);
-then += QEMU_JOB_WAIT_TIME;
+then += driver->job_wait_time;
virDomainObjRef(obj);
qemuDriverUnlock(driver);
@@ -3022,7 +3021,7 @@ static int qemudDomainShutdown(virDomainPtr dom) {
goto cleanup;
}
-if (qemuDomainObjBeginJob(vm) < 0)
+if (qemuDomainObjBeginJob(driver, vm) < 0)
goto cleanup;
if (!virDomainObjIsActive(vm)) {
@@ -3203,7 +3202,7 @@ static int qemudDomainSetMemory(virDomainPtr dom,
unsigned long newmem) {
goto cleanup;
}
-if (qemuDomainObjBeginJob(vm) < 0)
+if (qemuDomainObjBeginJob(driver, vm) < 0)
goto cleanup;
if (virDomainObjIsActive(vm)) {
@@ -3269,7 +3268,7 @@ static int qemudDomainGetInfo(virDomainPtr dom,
if (virDomainObjIsActive(vm)) {
qemuDomainObjPrivatePtr priv = vm->privateData;
if (!priv->jobActive) {
-if (qemuDomainObjBeginJob(vm) < 0)
+if (qemuDomainObjBeginJob(driver, vm) < 0)
goto cleanup;
qemuDomainObjEnterMonitor(vm);
@@ -3544,7 +3543,7 @@ static int qemudDomainCoreDump(virDomainPtr dom,
goto cleanup;
}
-if (qemuDomainObjBeginJob(vm) < 0)
+if (qemuDomainObjBeginJob(driver, vm) < 0)
goto cleanup;
if (!virDomainObjIsActive(vm)) {
@@ -3618,7 +3617,7 @@ static int qemudDomainSetVcpus(virDomainPtr dom, unsigned
int nvcpus) {
goto cleanup;
}
-if (qemuDomainObjBeginJob(vm) < 0)
+if (qemuDomainObjBeginJob(driver, vm) < 0)
goto cleanup;
if (virDomainObjIsActive(vm)) {
@@ -4145,7 +4144,7 @@ static char *qemudDomainDumpXML(virDomainPtr dom,
/* Don't delay if someone's using the monitor, just use
* existing most recent data instead */
if (!priv->jobActive) {
-if (qemuDomainObjBeginJob(vm) < 0)
+if (qemuDomainObjBeginJob(driver, vm) < 0)
goto cleanup;
Re: [libvirt] libvirt strange behavior possibly bug with version 0.7.2
On Wed, Nov 11, 2009 at 07:48:41PM +0100, Ricardo Mendes wrote:
> >>>import libvirt
> >>>con=libvirt.open('xen:///')
> >> libvirt.getVersion()
> 7002
> >>>dom=con.defineXML('rtiago_test2 >>>offset="utc"/>8restart >>> device="disk" type="file"> >>>name="file"/> >>>tty="/dev/pts/2" type="pty"> >>>port="0"/>restart3030restart/root/vmlinuz/root/initrd.imglinux/dev/xvda1
> >>> rortiago')
>
> >>> dom.create()
> >>>0
>
> >>> dom.destroy()
> >>> 0
>
> >>> dom.create()
> Traceback (most recent call last):
> File "", line 1, in ?
> File "/usr/lib64/python2.4/site-packages/libvirt.py", line 287, in create
> if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self)
> libvirt.libvirtError: Unknown failure
>
> Every call to create will raise the same exception, It only works if I do a
> new connection to the
> hypervisor. Is there an workaround??
It depends on what you are trying to do. If you have a persistent domain
XML that you want to keep, define it once with defineXML and later get
access to it with conn.lookupByName() or friends, create(), and finally
destroy() it.
Anyway, dom.destroy() makes the dom object useless as the name may
suggest ;-)
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] python bindings: override virDomainGetVcpus doc
--- python/libvirt-override-api.xml |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/python/libvirt-override-api.xml b/python/libvirt-override-api.xml index 148b89b..e7b5cbe 100644 --- a/python/libvirt-override-api.xml +++ b/python/libvirt-override-api.xml @@ -118,7 +118,7 @@ - Extract information about virtual CPUs of domain, store it in info array and also in cpumaps if this pointer is'nt NULL. + Extract information about virtual CPUs of domain. Return two lists: one with cpuinfo per vcpu, and the other with cpu affinity map per vcpu. -- 1.6.5.2 -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] chardev: Add function to output -chardev options
Would you please rebasae the legacy -vmchannel support accordingly?
On Wed, Nov 04, 2009 at 03:57:32PM +, Matthew Booth wrote:
> Note that, on its own, this patch will generate a warning about an unused
> static
> function.
> ---
> src/qemu/qemu_conf.c | 68
> ++
> 1 files changed, 68 insertions(+), 0 deletions(-)
>
> diff --git a/src/qemu/qemu_conf.c b/src/qemu/qemu_conf.c
> index 2981b51..a9f6885 100644
> --- a/src/qemu/qemu_conf.c
> +++ b/src/qemu/qemu_conf.c
> @@ -1411,6 +1411,74 @@ qemuBuildHostNetStr(virConnectPtr conn,
> return 0;
> }
>
> +/* This function outputs a -chardev command line option which describes only
> the
> + * host side of the character device */
> +static void qemudBuildCommandLineChrDevChardevStr(virDomainChrDefPtr dev,
> + const char *const id,
> + virBufferPtr buf)
> +{
> +bool telnet;
> +switch(dev->type) {
> +case VIR_DOMAIN_CHR_TYPE_NULL:
> +virBufferVSprintf(buf, "null,id=%s", id);
> +break;
> +
> +case VIR_DOMAIN_CHR_TYPE_VC:
> +virBufferVSprintf(buf, "vc,id=%s", id);
> +break;
> +
> +case VIR_DOMAIN_CHR_TYPE_PTY:
> +virBufferVSprintf(buf, "pty,id=%s", id);
> +break;
> +
> +case VIR_DOMAIN_CHR_TYPE_DEV:
> +virBufferVSprintf(buf, "tty,id=%s,path=%s", id, dev->data.file.path);
> +break;
> +
> +case VIR_DOMAIN_CHR_TYPE_FILE:
> +virBufferVSprintf(buf, "file,id=%s,path=%s", id,
> dev->data.file.path);
> +break;
> +
> +case VIR_DOMAIN_CHR_TYPE_PIPE:
> +virBufferVSprintf(buf, "pipe,id=%s,path=%s", id,
> dev->data.file.path);
> +break;
> +
> +case VIR_DOMAIN_CHR_TYPE_STDIO:
> +virBufferVSprintf(buf, "stdio,id=%s", id);
> +break;
> +
> +case VIR_DOMAIN_CHR_TYPE_UDP:
> +virBufferVSprintf(buf,
> +
> "udp,id=%s,host=%s,port=%s,localaddr=%s,localport=%s",
> + id,
> + dev->data.udp.connectHost,
> + dev->data.udp.connectService,
> + dev->data.udp.bindHost,
> + dev->data.udp.bindService);
> +break;
> +
> +case VIR_DOMAIN_CHR_TYPE_TCP:
> +telnet = dev->data.tcp.protocol ==
> VIR_DOMAIN_CHR_TCP_PROTOCOL_TELNET;
> +virBufferVSprintf(buf,
> + "socket,id=%s,host=%s,port=%s%s%s",
> + id,
> + dev->data.tcp.host,
> + dev->data.tcp.service,
> + telnet ? ",telnet" : "",
> + dev->data.tcp.listen ? ",server,nowait" : "");
> +break;
> +
> +case VIR_DOMAIN_CHR_TYPE_UNIX:
> +virBufferVSprintf(buf,
> + "socket,id=%s,path=%s%s",
> + id,
> + dev->data.nix.path,
> + dev->data.nix.listen ? ",server,nowait" : "");
> +break;
> +}
> +}
> +
> +/* This function outputs an all-in-one character device command line option
> */
> static int qemudBuildCommandLineChrDevStr(virDomainChrDefPtr dev,
>char *buf,
>int buflen)
> --
> 1.6.2.5
>
> --
> Libvir-list mailing list
> Libvir-list@redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 2/2] Add support for legacy QEMU's -vmchannel command line option
On Tue, Nov 03, 2009 at 04:11:48PM +, Matthew Booth wrote:
> This patch allows the following to be specified in a qemu domain:
>
>
>
>
>
>
> This will output the following on the qemu command line:
>
> -vmchannel di:0200,unix:/tmp/vmchannel,server,nowait
>
> * docs/schemas/domain.rng: Add syntax for vmchannel channel type
> * src/conf/domain_conf.[ch]: Add domain xml support for vmchannel chrdev
> target
> * src/qemu/qemu_conf.c: Add qemu support for vmchannel chrdev target
> * tests/qemuxml2argvtest.c: Add test for vmchannel channel type
> * tests/qemuxml2xmltest.c: Add test for vmchannel channel type
> ---
> docs/schemas/domain.rng| 13 +++-
> src/conf/domain_conf.c | 32 ++-
> src/conf/domain_conf.h |2 +
> src/qemu/qemu_conf.c | 22 +
> .../qemuxml2argv-channel-vmchannel.args|1 +
> .../qemuxml2argv-channel-vmchannel.xml | 26
> tests/qemuxml2argvtest.c |1 +
> tests/qemuxml2xmltest.c|2 +
> 8 files changed, 96 insertions(+), 3 deletions(-)
> create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-channel-vmchannel.args
> create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-channel-vmchannel.xml
>
> diff --git a/docs/schemas/domain.rng b/docs/schemas/domain.rng
> index b75f17e..39a19ae 100644
> --- a/docs/schemas/domain.rng
> +++ b/docs/schemas/domain.rng
> @@ -1059,12 +1059,23 @@
>
>
>
> +
> +
> +
> +vmchannel
> +
> +
> +
> +
>
>
>
>
>
> -
> +
> +
> +
> +
>
>
>
> diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
> index 4689bac..376cb3b 100644
> --- a/src/conf/domain_conf.c
> +++ b/src/conf/domain_conf.c
> @@ -134,7 +134,8 @@ VIR_ENUM_IMPL(virDomainChrTarget,
> VIR_DOMAIN_CHR_TARGET_TYPE_LAST,
>"parallel",
>"serial",
>"console",
> - "guestfwd")
> + "guestfwd",
> + "vmchannel")
>
> VIR_ENUM_IMPL(virDomainChr, VIR_DOMAIN_CHR_TYPE_LAST,
>"null",
> @@ -1349,6 +1350,7 @@ virDomainChrDefParseXML(virConnectPtr conn,
> const char *targetType = NULL;
> const char *addrStr = NULL;
> const char *portStr = NULL;
> +const char *deviceidStr = NULL;
> virDomainChrDefPtr def;
>
> if (VIR_ALLOC(def) < 0) {
> @@ -1497,6 +1499,26 @@ virDomainChrDefParseXML(virConnectPtr conn,
> virSocketSetPort(def->target.addr, port);
> break;
>
> +case VIR_DOMAIN_CHR_TARGET_TYPE_VMCHANNEL:
> +deviceidStr = virXMLPropString(cur, "deviceid");
> +
> +if(deviceidStr == NULL) {
> +virDomainReportError(conn, VIR_ERR_INVALID_DOMAIN,
> + _("vmchannel channel does not "
> + "define a device id"));
> +goto error;
> +}
> +
> +unsigned int deviceid;
> +if(virStrToLong_ui(deviceidStr, NULL, 16, &deviceid) <
> 0) {
> +virDomainReportError(conn, VIR_ERR_INVALID_DOMAIN,
> + _("Invalid device id: %s"),
> + deviceidStr);
> +goto error;
> +}
> +def->target.deviceid = deviceid;
> +break;
> +
> default:
> virDomainReportError(conn, VIR_ERR_INVALID_DOMAIN,
> _("unexpected target type type %u"),
> @@ -1507,7 +1529,6 @@ virDomainChrDefParseXML(virConnectPtr conn,
> cur = cur->next;
> }
>
> -
> switch (def->type) {
> case VIR_DOMAIN_CHR_TYPE_NULL:
> /* Nada */
> @@ -1634,6 +1655,7 @@ cleanup:
> VIR_FREE(targetType);
> VIR_FREE(addrStr);
> VIR_FREE(portStr);
> +VIR_FREE(deviceidStr);
>
> return def;
>
> @@ -4118,6 +4140,7 @@ virDomainChrDefFormat(virConnectPtr conn,
> switch (def->targetType) {
> /* channel types are in a common channel element */
> case VIR_DOMAIN_CHR_TARGET_TYPE_GUESTFWD:
> +case VIR_DOMAIN_CHR_TARGET_TYPE_VMCHANNEL:
> elementName = "channel";
> break;
>
> @@ -4230,6 +4253,11 @@ virDomainChrDefFormat(virConnectPtr conn,
>addr, port);
> break;
>
> +case VIR_DOMAIN_CHR_TARGET_TYPE_VMCHANNEL:
> +virBufferVSprintf(buf, " deviceid='%.4X'/>\n",
> + def->target.deviceid);
> +break;
> +
> case VIR_DOMA
Re: [libvirt] [PATCH] give up python interpreter lock before calling cb
On Mon, Nov 02, 2009 at 04:17:10PM +, Daniel P. Berrange wrote: > On Mon, Nov 02, 2009 at 06:09:52PM +0200, Dan Kenigsberg wrote: > > suggested by danpb on irc > > --- > > python/libvirt-override.c |4 > > 1 files changed, 4 insertions(+), 0 deletions(-) > > > > diff --git a/python/libvirt-override.c b/python/libvirt-override.c > > index 5d24fd2..53e36c0 100644 > > --- a/python/libvirt-override.c > > +++ b/python/libvirt-override.c > > @@ -2355,7 +2355,9 @@ libvirt_virEventInvokeHandleCallback(PyObject *self > > ATTRIBUTE_UNUSED, > > opaque = (void *) PyvirVoidPtr_Get(py_opaque); > > > > if(cb) > > +LIBVIRT_BEGIN_ALLOW_THREADS > > cb (watch, fd, event, opaque); > > +LIBVIRT_END_ALLOW_THREADS > > You'll need some curly braces around that, otherwise it is doing > > if(cb) > LIBVIRT_BEGIN_ALLOW_THREADS > > cb (watch, fd, event, opaque); > LIBVIRT_END_ALLOW_THREADS grr. bad case of python poisoning. anyway, the patch is here only for you not to forget it.. -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] give up python interpreter lock before calling cb
suggested by danpb on irc --- python/libvirt-override.c |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/python/libvirt-override.c b/python/libvirt-override.c index 5d24fd2..53e36c0 100644 --- a/python/libvirt-override.c +++ b/python/libvirt-override.c @@ -2355,7 +2355,9 @@ libvirt_virEventInvokeHandleCallback(PyObject *self ATTRIBUTE_UNUSED, opaque = (void *) PyvirVoidPtr_Get(py_opaque); if(cb) +LIBVIRT_BEGIN_ALLOW_THREADS cb (watch, fd, event, opaque); +LIBVIRT_END_ALLOW_THREADS return VIR_PY_INT_SUCCESS; } @@ -2379,7 +2381,9 @@ libvirt_virEventInvokeTimeoutCallback(PyObject *self ATTRIBUTE_UNUSED, cb = (virEventTimeoutCallback) PyvirEventTimeoutCallback_Get(py_f); opaque = (void *) PyvirVoidPtr_Get(py_opaque); if(cb) +LIBVIRT_BEGIN_ALLOW_THREADS cb (timer, opaque); +LIBVIRT_END_ALLOW_THREADS return VIR_PY_INT_SUCCESS; } -- 1.6.2.5 -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] drop the -logrotate.conf from /etc/logrotate.d/ovirt-logrotate.conf
On Sun, Nov 01, 2009 at 11:31:00PM +0900, Ryota Ozaki wrote: > On Sun, Nov 1, 2009 at 8:58 PM, Dan Kenigsberg wrote: > > No Fedora package uses .conf in that directory; furthermore, rpmlint > > protests about it: the file name should match the name of the containing > > rpm. Let us conform. > > --- > > logrotate/ovirt-logrotate | 2 +- > > ovirt-node.spec.in | 4 ++-- > > scripts/ovirt-config-logging | 2 +- > > scripts/ovirt-functions | 2 +- > > 4 files changed, 5 insertions(+), 5 deletions(-) > > This patch should be sent to ovirt-de...@redhat.com or somewhere else. > > Regards, > ozaki-r > oops, sorry. -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] drop the -logrotate.conf from /etc/logrotate.d/ovirt-logrotate.conf
No Fedora package uses .conf in that directory; furthermore, rpmlint
protests about it: the file name should match the name of the containing
rpm. Let us conform.
---
logrotate/ovirt-logrotate|2 +-
ovirt-node.spec.in |4 ++--
scripts/ovirt-config-logging |2 +-
scripts/ovirt-functions |2 +-
4 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/logrotate/ovirt-logrotate b/logrotate/ovirt-logrotate
index a61af6f..ad32951 100644
--- a/logrotate/ovirt-logrotate
+++ b/logrotate/ovirt-logrotate
@@ -1,3 +1,3 @@
# Run each log rotation every 10 minutes
-*/10 * * * * root /usr/sbin/logrotate /etc/logrotate.d/ovirt-logrotate.conf
+*/10 * * * * root /usr/sbin/logrotate /etc/logrotate.d/ovirt-node-stateless
*/10 * * * * root /usr/sbin/logrotate /etc/logrotate.d/syslog
diff --git a/ovirt-node.spec.in b/ovirt-node.spec.in
index 3a8266e..20fea25 100644
--- a/ovirt-node.spec.in
+++ b/ovirt-node.spec.in
@@ -180,7 +180,7 @@ cd -
%{__install} -p -m0755 kinit/ovirt-kinit %{buildroot}%{_sysconfdir}/cron.hourly
%{__install} -p -m0644 logrotate/ovirt-logrotate
%{buildroot}%{_sysconfdir}/cron.d
-%{__install} -p -m0644 logrotate/ovirt-logrotate.conf
%{buildroot}%{_sysconfdir}/logrotate.d
+%{__install} -p -m0644 logrotate/ovirt-logrotate.conf
%{buildroot}%{_sysconfdir}/logrotate.d/ovirt-node-stateless
echo "oVirt Node release %{version}-%{release}" >
%{buildroot}%{_sysconfdir}/ovirt-release
mkdir -p %{buildroot}/%{_sysconfdir}/default
@@ -310,7 +310,7 @@ fi
%{_initrddir}/ovirt
%{_initrddir}/ovirt-post
%config %{_sysconfdir}/cron.hourly/ovirt-kinit
-%config %{_sysconfdir}/logrotate.d/ovirt-logrotate.conf
+%config %{_sysconfdir}/logrotate.d/ovirt-node-stateless
%config %{_sysconfdir}/cron.d/ovirt-logrotate
%{_sysconfdir}/ovirt-config-boot.d
%{_sysconfdir}/ovirt-config-setup.d
diff --git a/scripts/ovirt-config-logging b/scripts/ovirt-config-logging
index 464dfcb..de238b7 100755
--- a/scripts/ovirt-config-logging
+++ b/scripts/ovirt-config-logging
@@ -158,7 +158,7 @@ function prompt_user {
$syslog_server_protocol
fi
sed -c -i -e "s/^size=.*/size=${max_log_size}k/" \
-/etc/logrotate.d/ovirt-logrotate.conf
+/etc/logrotate.d/ovirt-node-stateless
return
;;
1)
diff --git a/scripts/ovirt-functions b/scripts/ovirt-functions
index 98e88e7..7e84415 100644
--- a/scripts/ovirt-functions
+++ b/scripts/ovirt-functions
@@ -28,7 +28,7 @@ OVIRT_CONFIG_FILES="\
/etc/default/ovirt \
/etc/sysconfig/network \
/etc/collectd.conf \
- /etc/logrotate.d/ovirt-logrotate.conf
+ /etc/logrotate.d/ovirt-node-stateless
"
# Save stdout to fd 6 and stderr to fd 7. Redirect normal stdout/stderr
--
1.6.2.5
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 2/4] Add a type for SPICE protocol
On Wed, Oct 28, 2009 at 05:01:48PM -0400, Hugh O. Brock wrote:
> On Wed, Oct 28, 2009 at 10:53:48PM +0200, Dan Kenigsberg wrote:
> > On Wed, Oct 28, 2009 at 07:57:05PM +, Daniel P. Berrange wrote:
> > > On Sun, Oct 25, 2009 at 10:54:19PM +, Daniel P. Berrange wrote:
> > > > On Sun, Oct 25, 2009 at 05:15:26PM +0200, Dan Kenigsberg wrote:
> > > > > Just stumpbled on another issue:
> > > > >
> > > > > On Tue, Sep 29, 2009 at 04:43:50PM +0100, Daniel P. Berrange wrote:
> > > > > > @@ -366,6 +367,13 @@ struct _virDomainGraphicsDef {
> > > > > > char *display;
> > > > > > int fullscreen : 1;
> > > > > > } desktop;
> > > > > > +struct {
> > > > > > +int port;
> > > > > > +int tlsPort;
> > > > > > +char *listenAddr;
> > > > > > +char *keymap;
> > > > > > +char *passwd;
> > > > > > +} spice;
> > > > > > } data;
> > > > > > };
> > > > >
> > > > > just like vnc, spice needs autoport here (as well as in the schema).
> > > > >
> > > > > I wanted to ignore that, however, migration is impossibly unreliable
> > > > > without autoport=yes - the destination may have the port binded to
> > > > > something else.
> > > >
> > > > Ok, i'll add that.
> > >
> > > BTW, is there any recommended port range to use for SPICETCP and
> > > TLS ports ? VNC for example starts at 5900 and searches upwards
> >
> > currently I use 5900 upward for spice ports too, and 5900 downward for
> > tlsPort. (better keep it this way to save changes in iptables)
>
> Dan K., isn't there some magical range from 5900-5999 or something
> that VDSM ignores? Or did I dream that?
No, you weren't dreaming. I hoped to save libvir-list from this vdsm's
historical oddity. Yes, in RHEV-H-2.1 we squander the 5891--5909 range.
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 2/4] Add a type for SPICE protocol
On Wed, Oct 28, 2009 at 07:57:05PM +, Daniel P. Berrange wrote:
> On Sun, Oct 25, 2009 at 10:54:19PM +, Daniel P. Berrange wrote:
> > On Sun, Oct 25, 2009 at 05:15:26PM +0200, Dan Kenigsberg wrote:
> > > Just stumpbled on another issue:
> > >
> > > On Tue, Sep 29, 2009 at 04:43:50PM +0100, Daniel P. Berrange wrote:
> > > > @@ -366,6 +367,13 @@ struct _virDomainGraphicsDef {
> > > > char *display;
> > > > int fullscreen : 1;
> > > > } desktop;
> > > > +struct {
> > > > +int port;
> > > > +int tlsPort;
> > > > +char *listenAddr;
> > > > +char *keymap;
> > > > +char *passwd;
> > > > +} spice;
> > > > } data;
> > > > };
> > >
> > > just like vnc, spice needs autoport here (as well as in the schema).
> > >
> > > I wanted to ignore that, however, migration is impossibly unreliable
> > > without autoport=yes - the destination may have the port binded to
> > > something else.
> >
> > Ok, i'll add that.
>
> BTW, is there any recommended port range to use for SPICETCP and
> TLS ports ? VNC for example starts at 5900 and searches upwards
currently I use 5900 upward for spice ports too, and 5900 downward for
tlsPort. (better keep it this way to save changes in iptables)
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] virsh edit not saving interface target specification
On Sun, Oct 25, 2009 at 01:13:01PM -0500, Neil Aggarwal wrote: > Nikolai: > > > As i said in the kvm list, did you do virsh define > > /path/to/xml before launching the vm again ? > > According to what I am seeing on the Internet, > virsh edit is equivalent to dumping the xml, > editing it, and calling define to update > it so it should be the same thing. > > However, just to test it, I did the following: > 1. Stopped the virtual machine > 2. Added the target directive to the >/etc/libvirt/qemu/jamm12a.xml file > 3. Ran virsh define /etc/libvirt/qemu/jamm12a.xml > > If I look at the jamm12a.xml file after the define > command, the target directive is no longer there. > For some reason, libvirt is removing it. > > If I start the virtual machine, it attaches > to vnet0 instead of vnet1. heh, surprisingly I stumbled on this today. target devices with the 'vnet' prefix are special: if you do not specify a target device, a device with the vnet prefix is created automatically. conversely, if libvirt sees a target device with that name, it assumes it's a remnant of an automatically-created device name. if you care about the name of the tap device, you must choose a more "original" name. but beware: anything but automatically-created names would cause collisions during migration in a multi-domain multi-host environment. Dan -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] doc nits
(sorry, these ones annoy me when they are online)
---
src/datatypes.c |4 ++--
src/libvirt.c | 22 +++---
2 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/src/datatypes.c b/src/datatypes.c
index 89ad309..0601a79 100644
--- a/src/datatypes.c
+++ b/src/datatypes.c
@@ -71,7 +71,7 @@ virNetworkFreeName(virNetworkPtr network, const char *name
ATTRIBUTE_UNUSED)
/**
* virInterfaceFreeName:
- * @interface: a interface object
+ * @interface: an interface object
*
* Destroy the interface object, this is just used by the interface hash
callback.
*
@@ -674,7 +674,7 @@ _("Failed to change interface mac address from %s to %s due
to differing lengths
* virReleaseInterface:
* @interface: the interface to release
*
- * Unconditionally release all memory associated with a interface.
+ * Unconditionally release all memory associated with an interface.
* The conn.lock mutex must be held prior to calling this, and will
* be released prior to this returning. The interface obj must not
* be used once this method returns.
diff --git a/src/libvirt.c b/src/libvirt.c
index 9e87900..f7a0761 100644
--- a/src/libvirt.c
+++ b/src/libvirt.c
@@ -291,7 +291,7 @@ virInitialize(void)
#ifdef WITH_DRIVER_MODULES
/* We don't care if any of these fail, because the whole point
* is to allow users to only install modules they want to use.
- * If they try to use a open a connection for a module that
+ * If they try to use an open a connection for a module that
* is not loaded they'll get a suitable error at that point
*/
virDriverLoadModule("test");
@@ -2050,7 +2050,7 @@ error:
* virDomainResume:
* @domain: a domain object
*
- * Resume an suspended domain, the process is restarted from the state where
+ * Resume a suspended domain, the process is restarted from the state where
* it was frozen by calling virSuspendDomain().
* This function may requires privileged access
*
@@ -3999,7 +3999,7 @@ error:
*
* The path parameter is the name of the network interface.
*
- * Domains may have more than network interface. To get stats for
+ * Domains may have more than one network interface. To get stats for
* each you should make multiple calls to this function.
*
* Individual fields within the stats structure may be returned
@@ -4680,7 +4680,7 @@ error:
* @domain: pointer to domain object, or NULL for Domain0
* @info: pointer to an array of virVcpuInfo structures (OUT)
* @maxinfo: number of structures in info array
- * @cpumaps: pointer to an bit map of real CPUs for all vcpus of this
+ * @cpumaps: pointer to a bit map of real CPUs for all vcpus of this
* domain (in 8-bit bytes) (OUT)
* If cpumaps is NULL, then no cpumap information is returned by the API.
* It's assumed there is cpumap in cpumaps array.
@@ -9202,7 +9202,7 @@ error:
* @xml: XML describing the secret.
* @flags: flags, use 0 for now
*
- * If XML specifies an UUID, locates the specified secret and replaces all
+ * If XML specifies a UUID, locates the specified secret and replaces all
* attributes of the secret specified by UUID by attributes specified in xml
* (any attributes not specified in xml are discarded).
*
@@ -9713,7 +9713,7 @@ virStreamRef(virStreamPtr stream)
* with the call, but may instead be delayed until a
* subsequent call.
*
- * A example using this with a hypothetical file upload
+ * An example using this with a hypothetical file upload
* API looks like
*
* virStreamPtr st = virStreamNew(conn, 0);
@@ -9805,7 +9805,7 @@ error:
* with the call, but may instead be delayed until a
* subsequent call.
*
- * A example using this with a hypothetical file download
+ * An example using this with a hypothetical file download
* API looks like
*
* virStreamPtr st = virStreamNew(conn, 0);
@@ -9896,7 +9896,7 @@ error:
* requested data source. This is simply a convenient alternative
* to virStreamSend, for apps that do blocking-I/o.
*
- * A example using this with a hypothetical file upload
+ * An example using this with a hypothetical file upload
* API looks like
*
* int mysource(virStreamPtr st, char *buf, int nbytes, void *opaque) {
@@ -9993,7 +9993,7 @@ cleanup:
* requested data sink. This is simply a convenient alternative
* to virStreamRecv, for apps that do blocking-I/o.
*
- * A example using this with a hypothetical file download
+ * An example using this with a hypothetical file download
* API looks like
*
* int mysink(virStreamPtr st, const char *buf, int nbytes, void *opaque) {
@@ -10174,7 +10174,7 @@ error:
* virStreamEventRemoveCallback:
* @stream: pointer to the stream object
*
- * Remove a event callback from the stream
+ * Remove an event callback from the stream
*
* Returns 0 on success, -1 on error
*/
@@ -10297,7 +10297,7 @@ error:
* Decrement the reference count on a stream, releasing
* the stream object if the reference count has hit zero
