On 04/10/2012 11:56 AM, Osier Yang wrote:
for i in $(find . -type f -name "*.py"); do \
sed -i -e 's/utils\.Python/utils/g' $i; \
done
---
env_clear.py |2 +-
generator.py |6 +++---
libvirt-test-api.py
On 04/10/2012 11:56 AM, Osier Yang wrote:
test-API tends to only support testing via libvirt Python
binding now, and moving it to utils makes sense.
---
utils/{Python => }/XMLParser.py|0
utils/{Python => }/check.py|0
utils/{Python => }/env_parser.py |0
utils/{
On 04/10/2012 11:56 AM, Osier Yang wrote:
repos/domain/destroy.py
repos/domain/resume.py
repos/domain/shutdown.py
repos/domain/start.py
repos/domain/suspend.py
---
repos/domain/destroy.py |2 +-
repos/domain/resume.py |2 +-
repos/domain/shutdown.py |2
On 04/09/2012 09:52 PM, Eric Blake wrote:
> v3 was here:
> https://www.redhat.com/archives/libvir-list/2012-April/msg00288.html
>
> changes from v3:
> - split v3 patch 8 into 1/18 and 9/18
> - incorporate Laine's review comments on v3 patches 1 and 2 (here 2 and 3)
> - fix more bugs found during t
Minimal patch to wire up all the pieces in the previous patches
to actually enable a block copy job. By minimal, I mean that
qemu creates the file (that is, no REUSE_EXT flag support yet),
SELinux must be disabled, a lock manager is not informed, and
the audit logs aren't updated. But those will
I realize that we have that behaviour for quite some times but I
wonder about it, basically we always dump an usb controller on the
XML domain format:
even if there is no USB device connected to the machine. The drawback
I see is that if we try to reuse (or migrate) that domain to an older
Expose the full abilities of virDomainBlockCopy.
* tools/virsh.c (blockJobImpl): Add --format option for block copy.
* tools/virsh.pod (blockcopy): Document this.
---
tools/virsh.c | 26 --
tools/virsh.pod | 10 +-
2 files changed, 25 insertions(+), 11 deleti
This copies heavily from qemuDomainSnapshotCreateSingleDiskActive(),
in order to set the SELinux label, obtain locking manager lease, and
audit the fact that we hand a new file over to qemu. Alas, releasing
the lease and label on failure or at the end of the mirroring is a
trickier prospect.
* sr
As mentioned several commits ago when the capability bits were added,
the new block copy storage migration sequence requires both the
'drive-mirror' and 'drive-reopen' monitor commands.
As of this[1] qemu email, both commands have been proposed but not yet
incorporated into the tree; in fact, the
QUESTION: should we parse and ignore on input, rather than
rejecting it? By rejecting it, I can't add a unit test, since the
unit test framework currently doesn't expose a way to trigger
internal parsing.
In order to track a block copy job across libvirtd restarts, we
need to save internal XML t
This is the bare minimum to end a copy job (of course, until a
later patch adds the ability to start a copy job, this patch
doesn't do much in isolation; I've just split the patches to
ease the review).
This patch intentionally avoids SELinux, lock manager, and audit
actions, saving that for a lat
This new API provides additional flexibility over what can be
crammed on top of virDomainBlockRebase (namely, the ability to
specify an arbitrary destination format, for things like copying
qcow2 into qed without having to pre-create the destination), at
the expense that it cannot be backported wit
Handle the new type of block copy event and info. Of course,
this patch does nothing until a later patch actually allows the
creation/abort of a block copy job.
* src/qemu/qemu_monitor_json.c (qemuMonitorJSONHandleBlockJobImpl)
(qemuMonitorJSONGetBlockJobInfoOne): Translate new job type.
* src/qe
for i in $(find . -type f -name "*.py"); do \
sed -i -e 's/utils\.Python/utils/g' $i; \
done
---
env_clear.py |2 +-
generator.py |6 +++---
libvirt-test-api.py|2 +-
parser.
RHEL-only
drive-mirror and drive-reopen are still under upstream qemu
discussion; as a result, RHEL decided to backport things under
a downstream name. Accommodate this alternate spelling. I
don't think it's worth trying to support both spellings at once:
if you build upstream libvirt on RHEL, y
Almost trivial; the trick was dealing with the fact that we're
stuck with 'unsigned long bandwidth' due to earlier design
decisions. Also, prefer the correct flag names (although we
intentionally chose the _SHALLOW and _REUSE_EXT values to be
equal, to allow for loose handling in our code).
* src
test-API tends to only support testing via libvirt Python
binding now, and moving it to utils makes sense.
---
utils/{Python => }/XMLParser.py|0
utils/{Python => }/check.py|0
utils/{Python => }/env_parser.py |0
utils/{Python => }/format.py |0
utils/{Python =
Rather than further overloading 'blockpull', I decided to create a
new virsh command to expose the new flags of virDomainBlockRebase.
Someday, I'd also like to make blockpull and blockcopy have a
synchronous mode, which blocks until the event happens or Ctrl-C
is pressed, as well as a --verbose fl
For now, disk migration via block copy job is not implemented. But
when we do implement it, we have to deal with the fact that qemu does
not provide an easy way to re-start a qemu process with mirroring
still intact (it _might_ be possible by using qemu -S then an
initial 'drive-mirror' with disk
repos/domain/destroy.py
repos/domain/resume.py
repos/domain/shutdown.py
repos/domain/start.py
repos/domain/suspend.py
---
repos/domain/destroy.py |2 +-
repos/domain/resume.py |2 +-
repos/domain/shutdown.py |2 +-
repos/domain/start.py|2 +-
repos/domain
From: Adam Litke
Qemu has changed the semantics of the "block_job_cancel" API. The original
qed implementation (pretty much only backported to RHEL 6.2 qemu) was
synchronous (ie. upon command completion, the operation was guaranteed to
be completely stopped). With the new semantics going into q
This copies some of the checks from snapshots regarding testing
when a file already exists. In the process, I noticed a missing
sanity check in snapshots: REUSE_EXT should require the destination
to already be present.
* src/qemu/qemu_driver.c (qemuDomainBlockRebase): Allow REUSE_EXT
flag.
(qemuD
In my testing, I was able to provoke an odd block pull failure:
$ virsh blockpull dom vda --bandwidth 1
error: Requested operation is not valid: No active operation on device:
drive-virtio-disk0
merely by using gdb to artifically wait to do the block job set speed
until after the pull had al
The new block copy storage migration sequence requires both the
'drive-mirror' action in 'transaction' (present if the 'drive-mirror'
standalone monitor command also exists) and the 'drive-reopen' monitor
command (it would be nice if that were also part of a 'transaction',
but the initial qemu impl
v3 was here:
https://www.redhat.com/archives/libvir-list/2012-April/msg00288.html
changes from v3:
- split v3 patch 8 into 1/18 and 9/18
- incorporate Laine's review comments on v3 patches 1 and 2 (here 2 and 3)
- fix more bugs found during testing
- upgrade to Paolo's latest build (which dropped
This patch introduces a new block job, useful for live storage
migration using pre-copy streaming.
Using a live VM with the backing chain:
base <- snap1 <- snap2
as the starting point, we have:
- virDomainBlockRebase(dom, disk, "/path/to/copy", 0,
VIR_DOMAIN_BLOCK_REBASE_COPY)
creates /path
From: Adam Litke
Without the VIR_DOMAIN_BLOCK_JOB_ABORT_ASYNC flag, libvirt will internally
poll using qemu's "query-block-jobs" API and will not return until the
operation has been completed. API users are advised that this operation
is unbounded and further interaction with the domain during t
On 04/09/2012 02:45 PM, Laine Stump wrote:
> On 04/06/2012 02:29 PM, Eric Blake wrote:
>> From: Adam Litke
>>
>> Qemu has changed the semantics of the "block_job_cancel" API. The original
>> qed implementation (pretty much only backported to RHEL 6.2 qemu) was
>> synchronous (ie. upon command com
On 04/09/2012 03:26 PM, Laine Stump wrote:
> On 04/06/2012 02:29 PM, Eric Blake wrote:
>> From: Adam Litke
>>
>> Without the VIR_DOMAIN_BLOCK_JOB_ABORT_ASYNC flag, libvirt will internally
>> poll
>> using qemu's "query-block-jobs" API and will not return until the operation
>> has
>> been comple
On 04/06/2012 02:29 PM, Eric Blake wrote:
> From: Adam Litke
>
> Without the VIR_DOMAIN_BLOCK_JOB_ABORT_ASYNC flag, libvirt will internally
> poll
> using qemu's "query-block-jobs" API and will not return until the operation
> has
> been completed. API users are advised that this operation is u
On 04/06/2012 02:29 PM, Eric Blake wrote:
> From: Adam Litke
>
> Qemu has changed the semantics of the "block_job_cancel" API. The original
> qed implementation (pretty much only backported to RHEL 6.2 qemu) was
> synchronous (ie. upon command completion, the operation was guaranteed to
> be comp
On 03/30/2012 03:07 PM, David L Stevens wrote:
This patch adds DHCP snooping support to libvirt. The learning method for
IP addresses is specified by setting the "ip_learning" variable to one of
"any" [default] (existing IP learning code), "none" (static only addresses)
or "dhcp" (DHCP snooping).
On 04/06/2012 01:13 PM, Stefan Berger wrote:
> Below code failed to compile on a 32 bit machine with error
>
> typewrappers.c: In function 'libvirt_intUnwrap':
> typewrappers.c:135:5: error: logical 'and' of mutually exclusive tests
> is always false [-Werror=logical-op]
> cc1: all warnings being
On 04/09/2012 12:28 AM, Justin Clift wrote:
> Hey everyone,
>
> Just noticed that Etsy uses libvirt:
>
>
> http://codeascraft.etsy.com/2012/03/13/making-it-virtually-easy-to-deploy-on-day-one/
>
> Of specific note, there's this bit:
>
> "Libvirt supports live migrations across non-shared s
On 04/07/2012 03:33 AM, Richard W.M. Jones wrote:
> However the above commit is later amended by this commit:
>
> --
> commit eaddec976ef06457fee4a4ce86b8c7ee906183b7
> Author: Michal Privoznik
> Date: Wed Aug 24 16:16:4
On 04/08/2012 09:40 PM, MATSUDA, Daiki wrote:
> I found typo in UML driver.
>
> MATSUDA Daiki
>
> --- libvirt-0.9.11/src/uml/uml_driver.c.orig2012-04-09
> 11:56:47.105695476 +0900
> +++ libvirt-0.9.11/src/uml/uml_driver.c 2012-04-09 11:56:56.653820665 +0900
> @@ -249,7 +249,7 @@ umlIdentifyCh
With support for multiple IP addresses per interface in place, this patch
now adds support for multiple IP addresses per interface to the DHCP
snooping code.
---
This patch applies to David Stevens's DHCP snooping patch v8 plus the
patch I applied on top of v8.
Testing:
Since the infrastructur
The goal of this patch is to prepare for support for multiple IP
addresses per interface in the DHCP snooping code.
Move the code for the IP address map that maps interface names to
IP addresses into their own file. Rename the functions on the way
but otherwise leave the code as-is. Initialize th
On 03/30/2012 03:07 PM, David L Stevens wrote:
This patch adds DHCP snooping support to libvirt. The learning method for
IP addresses is specified by setting the "ip_learning" variable to one of
"any" [default] (existing IP learning code), "none" (static only addresses)
or "dhcp" (DHCP snooping).
39 matches
Mail list logo
