We've noticed libvirt-tck test 100-apply-verify-host.t failing recently on
libvirt.git master and I finally got around to bisecting it to commit b3d06987.
I haven't looked at the test in detail, but it appears to expect a broadcast
address of 10.1.2.255, however finds an address of 0.0.0.0 after co
From: Derbyshev Dmitry
QEMU reports timestamp along with other memory statistics, but this information
is not saved into domain statistics.
It could be useful to determine if the data reported is fresh or not.
Balloon statistics are not reported in hrf, so no modifications are made in
qemu_moni
From: Derbyshev Dmitry
QEMU reports timestamp and available along with other memory statistics.
This information was not saved into domain statistics.
Changes since v1:
* Enum numeration fixed
* Macro getting "usage" field fixed
Changes since v2:
* previous patches were on wrong branch
* qem
From: Derbyshev Dmitry
'memtotal' in virtio drivers and qemu corresponds to 'available' in libvirt.
Because of that, 'stat-available-memory' is renamed into 'usable'.
Balloon statistics are not reported in hrf, so no modifications are made in
qemu_monitor_text.c.
Signed-off-by: Derbyshev Dmitry
ignore, wrong branch
5/31/2016 8:14 PM, Derbyshev Dmitriy пишет:
From: Derbyshev Dmitry
QEMU reports timestamp and available along with other memory statistics.
This information was not saved into domain statistics.
Changes since v1:
* Enum numeration fixed
* Macro getting "usage" field f
On Wed, Jun 01, 2016 at 11:11:40AM -0400, John Ferlan wrote:
> Or just the raw text in a file. Too bad we couldn't link to the secret
> driver file directly...
BTW the real for never directly pointing qemu/qemu-img at the files
maintained by the secret driver itself is that we don't want to bake
i
On Wed, Jun 01, 2016 at 11:11:40AM -0400, John Ferlan wrote:
>
>
> On 06/01/2016 09:10 AM, Daniel P. Berrange wrote:
> > On Wed, Jun 01, 2016 at 09:04:00AM -0400, John Ferlan wrote:
> >> My quandary is less about the qemu-img infrastructure than the storage
> >> driver code.
> >>
> >> That is, it
On 06/01/2016 09:10 AM, Daniel P. Berrange wrote:
> On Wed, Jun 01, 2016 at 09:04:00AM -0400, John Ferlan wrote:
>> My quandary is less about the qemu-img infrastructure than the storage
>> driver code.
>>
>> That is, it's "less clear" in my mind how the storage_backend.c code
>> would need to ha
On 10/03/2016 19:09, Paolo Bonzini wrote:
> ===
> IMPORTANT DATES
> ===
> Notification: May 27, 2015
On behalf of the program committee, I apologize for the delay in sending
out the notifications. If you need to know in advance whether your talk
has been accepted, please
On Wed, Jun 01, 2016 at 09:04:00 -0400, John Ferlan wrote:
[...]
> In a way I was hoping that the ",data=" option could have been used, but
> that leaves a base64 encoded master key on the command line along with
> the base64 encoded secret and iv, which yes, would allow someone
> sufficiently pr
On Wed, Jun 01, 2016 at 02:03:17PM +0100, Daniel P. Berrange wrote:
> On Wed, Jun 01, 2016 at 02:49:26PM +0200, Marc Richter wrote:
> > Hi everyone,
> >
> > please, don't roast me if I'm asking stupid things or fail to provide info,
> > since I'm a freshman, using libvirt.
>
> No problem, we're a
On Wed, Jun 01, 2016 at 09:04:00AM -0400, John Ferlan wrote:
> My quandary is less about the qemu-img infrastructure than the storage
> driver code.
>
> That is, it's "less clear" in my mind how the storage_backend.c code
> would need to handle a ",file=" for its short lived master key. Where to
>
On 05/31/2016 06:39 PM, John Ferlan wrote:
> v1: http://www.redhat.com/archives/libvir-list/2016-May/msg02017.html
>
> Changes in v2:
>
> Patch 1 - Move function to a new src/util/virqemu.c with adjustments
> to other affected areas
>
> Patches 2-4 - Similarly adjust the flow/name of the patch
On 06/01/2016 06:43 AM, Peter Krempa wrote:
> On Tue, May 31, 2016 at 12:47:52 -0400, John Ferlan wrote:
>> On 05/31/2016 10:10 AM, Peter Krempa wrote:
>>> On Tue, May 31, 2016 at 09:49:45 -0400, John Ferlan wrote:
On 05/31/2016 08:10 AM, Peter Krempa wrote:
>
> [...]
>
>From that sam
On Wed, Jun 01, 2016 at 02:49:26PM +0200, Marc Richter wrote:
> Hi everyone,
>
> please, don't roast me if I'm asking stupid things or fail to provide info,
> since I'm a freshman, using libvirt.
No problem, we're a friendly lot here :-)
> Then a domain named "winxp_ausgeschaltet" is within that
Hi everyone,
please, don't roast me if I'm asking stupid things or fail to provide
info, since I'm a freshman, using libvirt.
I have two servers, both running the following versions:
Compiled against library: libvirt 1.3.1
Using library: libvirt 1.3.1
Using API: QEMU 1.3.1
Running hypervisor:
On Wed, Jun 01, 2016 at 14:23:54 +0300, Nikolay Shirokovskiy wrote:
> Hi, everyone.
>
> Cpu mode 'host-model' is not convinient for migration in current form.
> Consider migration from less capable host to more capable one - it is
> possible.
> But then migration backwards is impossible despi
On 06/01/2016 07:23 AM, Nikolay Shirokovskiy wrote:
> Hi, everyone.
>
> Cpu mode 'host-model' is not convinient for migration in current form.
> Consider migration from less capable host to more capable one - it is
> possible.
> But then migration backwards is impossible despite the fact that
Hi, everyone.
Cpu mode 'host-model' is not convinient for migration in current form.
Consider migration from less capable host to more capable one - it is possible.
But then migration backwards is impossible despite the fact that qemu process
on destination is running with the same model and f
On Tue, May 31, 2016 at 12:47:52 -0400, John Ferlan wrote:
> On 05/31/2016 10:10 AM, Peter Krempa wrote:
> > On Tue, May 31, 2016 at 09:49:45 -0400, John Ferlan wrote:
> >> On 05/31/2016 08:10 AM, Peter Krempa wrote:
[...]
> >> >From that same 2.6 wiki pointer, you'll note that the qemu-img forma
On Tue, May 31, 2016 at 03:00:24PM -0700, Stefan Hajnoczi wrote:
> On Thu, May 19, 2016 at 10:27:17AM +0100, Daniel P. Berrange wrote:
> > On Mon, May 16, 2016 at 04:58:48PM -0700, Stefan Hajnoczi wrote:
> > > On Wed, May 11, 2016 at 03:42:34PM +0100, Daniel P. Berrange wrote:
> > > > On Tue, May 1
On 01/06/16 10:21, Fabian Freyer wrote:
> A simpe getopt-based argument parser is added for the /usr/sbin/bhyve command,
> loosely based on its argument parser, which reads the following from the bhyve
> command line string:
getopt is not thread safe, so can't use that here. There are a number of
On Tue, May 31, 2016 at 10:59:18AM -0700, Ansis Atteka wrote:
> On 31 May 2016 at 09:36, Daniel P. Berrange wrote:
>
> > On Mon, May 30, 2016 at 01:27:46PM -0700, Ansis Atteka wrote:
> > > On Mon, May 30, 2016 at 12:29 AM, Christian Ehrhardt
> > > wrote:
> > > > On Tue, May 24, 2016 at 4:10 PM,
A simple getopt-based argument parser is added for the /usr/sbin/bhyveload
command, loosely based on its argument parser.
The boot disk is guessed by iterating over all
disks and matching their sources. If any non-default arguments are found,
def->os.bootloaderArgs is set accordingly, and the boot
A simpe getopt-based argument parser is added for the /usr/sbin/bhyve command,
loosely based on its argument parser, which reads the following from the bhyve
command line string:
* vm name
* number of vcpus
* memory size
* the time offset (UTC or localtime). This includes a capability check to see
Remove escaped newlines and split up the string into an argv-list for
the bhyve and loader commands, respectively. This is done by iterating over the
string splitting it by newlines, and then re-iterating over each line,
splitting it by spaces.
Since this code reuses part of the code of qemu_parse
The following series of patches implement virConnectDomainXMLFromNative. This
is mostly some boiler plate code generating argv-lists from the native command
string, and two getopt-based argument parsers for the /usr/sbin/bhyve and
/usr/sbin/bhyveload commands.
Since there is quite some string hand
27 matches
Mail list logo
