Re: [libvirt] [PATCH 3/3] kvm-all: notice KVM of vcpu's TSC rate after migration

2015-09-28 Thread Haozhong Zhang 
On Mon, Sep 28, 2015 at 01:37:34PM -0300, Eduardo Habkost wrote:
> On Mon, Sep 28, 2015 at 01:38:31PM +0800, Haozhong Zhang wrote:
> > When a vcpu is created in KVM, its TSC rate is initially identical to
> > the host TSC rate. If its state is migrated to a vcpu on another
> > machine (target machine) which may uses a different host TSC rate, QEMU
> > on the target machine should notice KVM of the migrated vcpu's TSC
> > rate. In case that KVM on the target machine supports TSC scaling, guest
> > programs running on the migrated vcpu will observe the same TSC rate
> > before and after the migration.
> > 
> > Signed-off-by: Haozhong Zhang 
> > ---
> >  kvm-all.c | 13 +
> >  1 file changed, 13 insertions(+)
> > 
> > diff --git a/kvm-all.c b/kvm-all.c
> > index 0be4615..e8de038 100644
> > --- a/kvm-all.c
> > +++ b/kvm-all.c
> > @@ -1769,6 +1769,19 @@ void kvm_cpu_synchronize_post_reset(CPUState *cpu)
> >  static void do_kvm_cpu_synchronize_post_init(void *arg)
> >  {
> >  CPUState *cpu = arg;
> > +CPUX86State *env = _CPU(cpu)->env;
> > +int r;
> > +
> > +/*
> > + * XXX: KVM_SET_TSC_KHZ must be done before kvm_arch_put_registers().
> 
> Could you explain where this requirement comes from?
>

kvm_arch_put_registers() below will setup vcpu's MSR_IA32_TSC through
KVM ioctl KVM_SET_MSRS. KVM needs to know vcpu's TSC rate so as to
correctly scale the TSC value given by QEMU, especially when vcpu's
TSC rate is different than the host TSC rate (e.g. it's migrated from
another machine w/ different host TSC rate than the current one).

> > + */
> > +r = kvm_check_extension(cpu->kvm_state, KVM_CAP_TSC_CONTROL);
> > +if (r && env->tsc_khz) {
> > +r = kvm_vcpu_ioctl(cpu, KVM_SET_TSC_KHZ, env->tsc_khz);
> > +if (r < 0) {
> > +fprintf(stderr, "KVM_SET_TSC_KHZ failed\n");
> > +}
> > +}
> 
> This is duplicating the existing KVM_SET_TSC_KHZ call at
> kvm_arch_init_vcpu(). I wonder if there's a way to avoid this
> duplication. Should we set TSC KHz only at
> do_kvm_cpu_synchronize_post_init(), and remove the call from
> kvm_arch_init_vcpu()?
>

I'll check if it's safe to remove the call from kvm_arch_init_vcpu().

> Or maybe we shouldn't treat this as VM state, but as configuration, and
> let management configure the TSC frequency explicitly if the user really
> needs it to stay the same during migration.
>
> (CCing libvir-list to see if they have feedback)
>

Thanks for CC. I'll consider to add a command line option to control
the configuration of guest TSC fequency.

> -- 
> Eduardo

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [libvirt-test-API] [PATCH] Add test cases for API defineXMLFlags

2015-09-28 Thread Shanzhi Yu 
Signed-off-by: Shanzhi Yu 
---
 cases/linux_domain.conf |  22 +
 repos/domain/definewithflags.py | 104 
 2 files changed, 126 insertions(+)
 create mode 100644 repos/domain/definewithflags.py

diff --git a/cases/linux_domain.conf b/cases/linux_domain.conf
index 6315613..7dd9062 100644
--- a/cases/linux_domain.conf
+++ b/cases/linux_domain.conf
@@ -214,6 +214,28 @@ domain:define
 macaddr
 54:52:00:45:c3:8a
 
+domain:undefine
+guestname
+$defaultname
+
+domain:definewithflags
+guestname
+$defaultname
+diskpath
+/var/lib/libvirt/images/libvirt-test-api
+vcpu
+1
+memory
+1048576
+hddriver
+virtio
+nicdriver
+virtio
+macaddr
+54:52:00:45:c3:8a
+flags
+validate
+
 domain:start
 guestname
 $defaultname
diff --git a/repos/domain/definewithflags.py b/repos/domain/definewithflags.py
new file mode 100644
index 000..01a4f15
--- /dev/null
+++ b/repos/domain/definewithflags.py
@@ -0,0 +1,104 @@
+#!/usr/bin/evn python
+
+import os
+import re
+import sys
+import commands
+import string
+import pexpect
+
+import libvirt
+from libvirt import libvirtError
+
+from src import sharedmod
+from utils import utils
+
+required_params = ('guestname', 'diskpath', 'flags',)
+optional_params = {'memory': 1048576,
+   'vcpu': 1,
+   'imageformat' : 'raw',
+   'hddriver' : 'virtio',
+   'nicdriver': 'virtio',
+   'macaddr': '52:54:00:97:e4:28',
+   'uuid' : '05867c1a-afeb-300e-e55e-2673391ae080',
+   'username': None,
+   'password': None,
+   'virt_type': 'kvm',
+   'xml': 'xmls/kvm_guest_define.xml',
+   'guestarch': 'x86_64',
+   'guestmachine': 'pc',
+  }
+
+def check_define_domain(guestname, virt_type, hostname, username, \
+password, logger):
+"""Check define domain result, if define domain is successful,
+   guestname.xml will exist under /etc/libvirt/qemu/
+   and can use virt-xml-validate tool to check the file validity
+"""
+if "kvm" in virt_type:
+path = "/etc/libvirt/qemu/%s.xml" % guestname
+elif "xen" in virt_type:
+path = "/etc/xen/%s" % guestname
+else:
+logger.error("unknown virt type")
+
+if hostname:
+cmd = "ls %s" % path
+ret, output = utils.remote_exec_pexpect(hostname, username, \
+   password, cmd)
+if ret:
+logger.error("guest %s xml file doesn't exsits" % guestname)
+return False
+else:
+return True
+else:
+if os.access(path, os.R_OK):
+return True
+else:
+return False
+
+def definewithflags(params):
+"""Define a domain from xml"""
+logger = params['logger']
+guestname = params['guestname']
+
+xmlstr = params['xml']
+logger.debug("domain xml:\n%s" % xmlstr)
+
+conn = sharedmod.libvirtobj['conn']
+uri = conn.getURI()
+
+hostname = utils.parse_uri(uri)[1]
+username = params.get('username', '')
+password = params.get('password', '')
+virt_type = params.get('virt_type', 'kvm')
+
+flags = params['flags']
+logger.info("The flags are %s" % flags)
+flags_string = flags.split("|")
+flags = 0
+
+logger.info("define domain on %s" % uri)
+
+for flag in flags_string:
+if flag == 'validate':
+flags |= libvirt.VIR_DOMAIN_DEFINE_VALIDATE
+else:
+logger.error("unknow flags")
+return 1
+
+# Define domain from xml
+try:
+conn.defineXMLFlags(xmlstr, flags)
+if check_define_domain(guestname, virt_type, hostname, \
+   username, password, logger):
+logger.info("define a domain from xml is successful")
+else:
+logger.error("fail to check define domain")
+return 1
+except libvirtError, e:
+logger.error("API error message: %s, error code is %s" \
+ % (e.message, e.get_error_code()))
+return 1
+
+return 0
-- 
1.8.3.1

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 0/2] Add support for gic-version machine option

2015-09-28 Thread Martin Kletzander 

On Mon, Sep 28, 2015 at 08:26:22PM +0300, Pavel Fedin wrote:

Hello!


It's nice that QEMU complains itself, but in a case where it is that
easy to check the supportability I think it's worth adding because
then at least we won't prepare all the stuff and can error out early.


Huh...
I am looking at it now, but looks like there's no support for getting machine 
properties in QMP.
Or, at least, it's not documented. The easy way would be based on version 
number (actually we
already do this with QEMU_CAPS_MACHINE_USB_OPT). Will it be OK?



If there is no other option, then we have nothing to choose from, so
it's OK to have it checked by version in this particular case.

Later on libvirt should support QEMU's QMP introspection from Markus,
but that's a future thing.

Thanks,
Martin


Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia




signature.asc
Description: PGP signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH] qemu: Fix dynamic_ownership qemu.conf setting

2015-09-28 Thread Martin Kletzander 

On Mon, Sep 28, 2015 at 07:53:42PM -0400, Cole Robinson wrote:

Commit 307fb904 (Sep 10) added a 'privileged' variable when creating
the DAC driver:

@@ -153,6 +157,7 @@ virSecurityManagerNewDAC(const char *virtDriver,
 bool defaultConfined,
 bool requireConfined,
 bool dynamicOwnership,
+ bool privileged,
 virSecurityManagerDACChownCallback chownCallback)

But argument order is mixed up at the caller, swapping dynamicOwnership
and privileged values. This corrects the argument order



I'm pretty sure I noticed this during review. I must've failed to
inform the author because I see no reply to the patch that caused it.

ACK and safe for freeze!


https://bugzilla.redhat.com/show_bug.cgi?id=1266628
---
src/qemu/qemu_driver.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index 7025c51..aff1915 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -431,8 +431,8 @@ qemuSecurityInit(virQEMUDriverPtr driver)
 cfg->allowDiskFormatProbing,
 cfg->securityDefaultConfined,
 cfg->securityRequireConfined,
- virQEMUDriverIsPrivileged(driver),
 cfg->dynamicOwnership,
+ virQEMUDriverIsPrivileged(driver),
 qemuSecurityChownCallback)))
goto error;
if (!stack) {
--
2.5.0

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list


signature.asc
Description: PGP signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [libvirt-test-API] [PATCH] fix some typo

2015-09-28 Thread Shanzhi Yu 
Signed-off-by: Shanzhi Yu 
---
 repos/domain/fsinfo.py  | 2 +-
 repos/domain/install_linux_check.py | 2 +-
 repos/domain/install_linux_net.py   | 2 +-
 repos/interface/define.py   | 2 +-
 repos/interface/undefine.py | 4 ++--
 5 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/repos/domain/fsinfo.py b/repos/domain/fsinfo.py
index e6d1bf0..d4614f5 100644
--- a/repos/domain/fsinfo.py
+++ b/repos/domain/fsinfo.py
@@ -81,7 +81,7 @@ def fsinfo(params):
 return 1
 
 fsinfo = vm.fsInfo()
-logger.info("get geust filesystem information")
+logger.info("get guest filesystem information")
 
 mac = get_guest_mac(vm)
 if not mac:
diff --git a/repos/domain/install_linux_check.py 
b/repos/domain/install_linux_check.py
index ab1e7db..bb3cc2a 100644
--- a/repos/domain/install_linux_check.py
+++ b/repos/domain/install_linux_check.py
@@ -99,7 +99,7 @@ def install_linux_check(params):
 Test_Result = 1
 return Test_Result
 
-# Check whether vcpu equals the value set in geust config xml
+# Check whether vcpu equals the value set in guest config xml
 logger.info("check point3: check cpu number in guest equals to \
  the value set in domain config xml")
 vcpunum_expect = int(utils.get_num_vcpus(domain_name))
diff --git a/repos/domain/install_linux_net.py 
b/repos/domain/install_linux_net.py
index 4367d97..7173294 100644
--- a/repos/domain/install_linux_net.py
+++ b/repos/domain/install_linux_net.py
@@ -239,7 +239,7 @@ def install_linux_net(params):
 logger.info("booting guest vm off harddisk failed")
 return 1
 else:
-logger.info("geust is booting up")
+logger.info("guest is booting up")
 else:
 interval = 0
 while(interval < 3600):
diff --git a/repos/interface/define.py b/repos/interface/define.py
index 18ba71b..e0dbcf4 100644
--- a/repos/interface/define.py
+++ b/repos/interface/define.py
@@ -42,7 +42,7 @@ def define(params):
 try:
 conn.interfaceDefineXML(xmlstr, 0)
 if check_define_interface(ifacename):
-logger.info("define a interface form xml is successful")
+logger.info("define a interface from xml is successful")
 else:
 logger.error("fail to check define interface")
 return 1
diff --git a/repos/interface/undefine.py b/repos/interface/undefine.py
index f9b2d74..8b250de 100644
--- a/repos/interface/undefine.py
+++ b/repos/interface/undefine.py
@@ -39,14 +39,14 @@ def undefine(params):
 try:
 ifaceobj.undefine()
 if check_undefine_interface(ifacename):
-logger.info("undefine a interface form xml is successful")
+logger.info("undefine a interface is successful")
 else:
 logger.error("fail to check undefine interface")
 return 1
 except libvirtError, e:
 logger.error("API error message: %s, error code is %s" \
  % (e.message, e.get_error_code()))
-logger.error("fail to undefine a interface from xml")
+logger.error("fail to undefine a interface")
 return 1
 
 return 0
-- 
1.8.3.1

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 3/3] kvm-all: notice KVM of vcpu's TSC rate after migration

2015-09-28 Thread Eduardo Habkost 
On Mon, Sep 28, 2015 at 01:38:31PM +0800, Haozhong Zhang wrote:
> When a vcpu is created in KVM, its TSC rate is initially identical to
> the host TSC rate. If its state is migrated to a vcpu on another
> machine (target machine) which may uses a different host TSC rate, QEMU
> on the target machine should notice KVM of the migrated vcpu's TSC
> rate. In case that KVM on the target machine supports TSC scaling, guest
> programs running on the migrated vcpu will observe the same TSC rate
> before and after the migration.
> 
> Signed-off-by: Haozhong Zhang 
> ---
>  kvm-all.c | 13 +
>  1 file changed, 13 insertions(+)
> 
> diff --git a/kvm-all.c b/kvm-all.c
> index 0be4615..e8de038 100644
> --- a/kvm-all.c
> +++ b/kvm-all.c
> @@ -1769,6 +1769,19 @@ void kvm_cpu_synchronize_post_reset(CPUState *cpu)
>  static void do_kvm_cpu_synchronize_post_init(void *arg)
>  {
>  CPUState *cpu = arg;
> +CPUX86State *env = _CPU(cpu)->env;
> +int r;
> +
> +/*
> + * XXX: KVM_SET_TSC_KHZ must be done before kvm_arch_put_registers().

Could you explain where this requirement comes from?

> + */
> +r = kvm_check_extension(cpu->kvm_state, KVM_CAP_TSC_CONTROL);
> +if (r && env->tsc_khz) {
> +r = kvm_vcpu_ioctl(cpu, KVM_SET_TSC_KHZ, env->tsc_khz);
> +if (r < 0) {
> +fprintf(stderr, "KVM_SET_TSC_KHZ failed\n");
> +}
> +}

This is duplicating the existing KVM_SET_TSC_KHZ call at
kvm_arch_init_vcpu(). I wonder if there's a way to avoid this
duplication. Should we set TSC KHz only at
do_kvm_cpu_synchronize_post_init(), and remove the call from
kvm_arch_init_vcpu()?

Or maybe we shouldn't treat this as VM state, but as configuration, and
let management configure the TSC frequency explicitly if the user really
needs it to stay the same during migration.

(CCing libvir-list to see if they have feedback)

-- 
Eduardo

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH] virDomainDiskDef: Turn @device into enum

2015-09-28 Thread Laine Stump 

On 09/17/2015 11:37 AM, Michal Privoznik wrote:

It's used as enum everywhere, so why store its value in an int?


There are a lot of these. I *think* the only reason this was done 
anywhere in the first place was because the size of an enum isn't 
guaranteed to be the same across different platforms, so you can't use 
an enum type in any wire protocol (e.g. libvirt client to server), and 
somehow this usage leaked over into the internal-only data structures; 
after that  the general "that works! Copy it!" cargo cult generation of 
new code meant that we now have lots of instances of this (there may 
also be cases where someone chose to use -1 to indicate "not specified" 
rather than 0/the first enum value).


Or it could be there's some other reason for using int instead of an 
enum type in the internal config objects that I've forgotten.


--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 0/2] Add support for gic-version machine option

2015-09-28 Thread Pavel Fedin 
 Hello!

> It's nice that QEMU complains itself, but in a case where it is that
> easy to check the supportability I think it's worth adding because
> then at least we won't prepare all the stuff and can error out early.

 Huh...
 I am looking at it now, but looks like there's no support for getting machine 
properties in QMP.
Or, at least, it's not documented. The easy way would be based on version 
number (actually we
already do this with QEMU_CAPS_MACHINE_USB_OPT). Will it be OK?

Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia


--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH] virDomainDiskDef: Turn @device into enum

2015-09-28 Thread Daniel P. Berrange 
On Mon, Sep 28, 2015 at 12:35:31PM -0400, Laine Stump wrote:
> On 09/17/2015 11:37 AM, Michal Privoznik wrote:
> >It's used as enum everywhere, so why store its value in an int?
> 
> There are a lot of these. I *think* the only reason this was done anywhere
> in the first place was because the size of an enum isn't guaranteed to be
> the same across different platforms, so you can't use an enum type in any
> wire protocol (e.g. libvirt client to server), and somehow this usage leaked
> over into the internal-only data structures; after that  the general "that
> works! Copy it!" cargo cult generation of new code meant that we now have
> lots of instances of this (there may also be cases where someone chose to
> use -1 to indicate "not specified" rather than 0/the first enum value).
> 
> Or it could be there's some other reason for using int instead of an enum
> type in the internal config objects that I've forgotten.

IIRC, it was because enum fields can be unsigned & we use -1 as the error
code for virEnumFromString(). So if you have

enum foo;

if ((foo = virEnumFromString("blah")) < 0)
...error handling...

your error handling would not get run, as the -1 would get turned into a
high positive value.

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] [PATCH v2] Close the source fd if the destination qemu exits during tunnelled migration

2015-09-28 Thread John Ferlan 


On 09/28/2015 11:02 AM, Shivaprasad bhat wrote:
> Hi Jon,
> 
> Thanks a lot for attaching the patch.  Replies inline.
> 
> On Thu, Sep 24, 2015 at 1:52 AM, John Ferlan  wrote:
>>
>>
>> On 09/22/2015 07:21 AM, Shivaprasad bhat wrote:
>>> On Mon, Sep 21, 2015 at 8:04 PM, John Ferlan  wrote:


 On 09/21/2015 05:09 AM, Shivaprasad bhat wrote:
> Thanks John for the comments.
>
>
> On Fri, Sep 18, 2015 at 10:34 PM, John Ferlan  wrote:
>>
>>
>> On 09/14/2015 10:44 AM, Shivaprasad G Bhat wrote:
>>> Tunnelled migration can hang if the destination qemu exits despite all 
>>> the
>>> ABI checks. This happens whenever the destination qemu exits before the
>>> complete transfer is noticed by source qemu. The savevm state checks at
>>> runtime can fail at destination and cause qemu to error out.
>>> The source qemu cant notice it as the EPIPE is not propogated to it.
>>> The qemuMigrationIOFunc() notices the stream being broken from 
>>> virStreamSend()
>>> and it cleans up the stream alone. The qemuMigrationWaitForCompletion() 
>>> would
>>> never get to 100% transfer completion.
>>> The qemuMigrationWaitForCompletion() never breaks out as well since
>>> the ssh connection to destination is healthy, and the source qemu also 
>>> thinks
>>> the migration is ongoing as the Fd to which it transfers, is never
>>> closed or broken. So, the migration will hang forever. Even Ctrl-C on 
>>> the
>>> virsh migrate wouldn't be honoured. Close the source side FD when there 
>>> is
>>> an error in the stream. That way, the source qemu updates itself and
>>> qemuMigrationWaitForCompletion() notices the failure.
>>>
>>> Close the FD for all kinds of errors to be sure. The error message is 
>>> not
>>> copied for EPIPE so that the destination error is copied instead later.
>>>
>>> Note:
>>> Reproducible with repeated migrations between Power hosts running in 
>>> different
>>> subcores-per-core modes.
>>>
>>> Changes from v1 -> v2:
>>>VIR_FORCE_CLOSE() was called twice for this use case which would log
>>>unneccessary warnings. So, move the fd close to qemuMigrationIOFunc
>>>so that there are no unnecessary duplicate attempts.(Would this 
>>> trigger
>>>a Coverity error? I don't have a setup to check.)
>>>
>>> Signed-off-by: Shivaprasad G Bhat 
>>> ---
>>>  src/qemu/qemu_migration.c |8 ++--
>>>  1 file changed, 6 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c
>>> index ff89ab5..9602fb2 100644
>>> --- a/src/qemu/qemu_migration.c
>>> +++ b/src/qemu/qemu_migration.c
>>> @@ -4012,6 +4012,7 @@ static void qemuMigrationIOFunc(void *arg)
>>>  if (virStreamFinish(data->st) < 0)
>>>  goto error;
>>>
>>> +VIR_FORCE_CLOSE(data->sock);
>>>  VIR_FREE(buffer);
>>>
>>>  return;
>>> @@ -4029,7 +4030,11 @@ static void qemuMigrationIOFunc(void *arg)
>>>  }
>>>
>>>   error:
>>> -virCopyLastError(>err);
>>> +/* Let the source qemu know that the transfer cant continue 
>>> anymore.
>>> + * Don't copy the error for EPIPE as destination has the actual 
>>> error. */
>>> +VIR_FORCE_CLOSE(data->sock);
>>> +if (!virLastErrorIsSystemErrno(EPIPE))
>>> +virCopyLastError(>err);
>>>  virResetLastError();
>>>  VIR_FREE(buffer);
>>>  }
>>> @@ -4397,7 +4402,6 @@ qemuMigrationRun(virQEMUDriverPtr driver,
>>>  if (iothread && qemuMigrationStopTunnel(iothread, ret < 0) < 0)
>>>  ret = -1;
>>>  }
>>> -VIR_FORCE_CLOSE(fd);
>>
>> ^^^
>>
>> This causes Coverity to claim a RESOURCE_LEAK
>>
>> Feels like this was a mistake edit...
>>
>
> The VIR_FORCE_CLOSE() inside qemuMigrationIOFunc() alone is sufficient.
> Having this again here would lead to Warning in the logs. I too thought 
> coverity
> would complain. Is there a way to force ignore a coverity warning?
>

 Typically a marker of sorts, such as

 /* coverity[leaked_handle]  */

 Although I'm not sure that's the best way to handle this either.

 The problem I see though is this is an "error path" issue and when
 perhaps it's safe/required to close fd/io->sock/data->sock.

 Your commit comment notes that the issue is seen on a fairly specific
 event (virStreamSend failure) for a specific type of migration.
>>>
>>> I believe the failure can be seen for all types of migration with savestate
>>> mismatch.
>>>
>>
>> My thoughts were based mostly on your commit message comments:
>>
>> "The qemuMigrationIOFunc() notices the stream

Re: [libvirt] [PATCH] virDomainDiskDef: Turn @device into enum

2015-09-28 Thread John Ferlan 


On 09/17/2015 11:37 AM, Michal Privoznik wrote:
> It's used as enum everywhere, so why store its value in an int?
> 
> Signed-off-by: Michal Privoznik 
> ---
>  src/conf/domain_conf.c   | 9 +++--
>  src/conf/domain_conf.h   | 2 +-
>  src/qemu/qemu_command.c  | 2 ++
>  src/vmx/vmx.c| 6 +++---
>  src/vmx/vmx.h| 2 +-
>  src/xenconfig/xen_sxpr.c | 4 +++-
>  6 files changed, 13 insertions(+), 12 deletions(-)
> 

Seems reasonable - ACK

John

Seems to be safe too


--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v2] Close the source fd if the destination qemu exits during tunnelled migration

2015-09-28 Thread Shivaprasad bhat 
Hi Jon,

Thanks a lot for attaching the patch.  Replies inline.

On Thu, Sep 24, 2015 at 1:52 AM, John Ferlan  wrote:
>
>
> On 09/22/2015 07:21 AM, Shivaprasad bhat wrote:
>> On Mon, Sep 21, 2015 at 8:04 PM, John Ferlan  wrote:
>>>
>>>
>>> On 09/21/2015 05:09 AM, Shivaprasad bhat wrote:
 Thanks John for the comments.


 On Fri, Sep 18, 2015 at 10:34 PM, John Ferlan  wrote:
>
>
> On 09/14/2015 10:44 AM, Shivaprasad G Bhat wrote:
>> Tunnelled migration can hang if the destination qemu exits despite all 
>> the
>> ABI checks. This happens whenever the destination qemu exits before the
>> complete transfer is noticed by source qemu. The savevm state checks at
>> runtime can fail at destination and cause qemu to error out.
>> The source qemu cant notice it as the EPIPE is not propogated to it.
>> The qemuMigrationIOFunc() notices the stream being broken from 
>> virStreamSend()
>> and it cleans up the stream alone. The qemuMigrationWaitForCompletion() 
>> would
>> never get to 100% transfer completion.
>> The qemuMigrationWaitForCompletion() never breaks out as well since
>> the ssh connection to destination is healthy, and the source qemu also 
>> thinks
>> the migration is ongoing as the Fd to which it transfers, is never
>> closed or broken. So, the migration will hang forever. Even Ctrl-C on the
>> virsh migrate wouldn't be honoured. Close the source side FD when there 
>> is
>> an error in the stream. That way, the source qemu updates itself and
>> qemuMigrationWaitForCompletion() notices the failure.
>>
>> Close the FD for all kinds of errors to be sure. The error message is not
>> copied for EPIPE so that the destination error is copied instead later.
>>
>> Note:
>> Reproducible with repeated migrations between Power hosts running in 
>> different
>> subcores-per-core modes.
>>
>> Changes from v1 -> v2:
>>VIR_FORCE_CLOSE() was called twice for this use case which would log
>>unneccessary warnings. So, move the fd close to qemuMigrationIOFunc
>>so that there are no unnecessary duplicate attempts.(Would this 
>> trigger
>>a Coverity error? I don't have a setup to check.)
>>
>> Signed-off-by: Shivaprasad G Bhat 
>> ---
>>  src/qemu/qemu_migration.c |8 ++--
>>  1 file changed, 6 insertions(+), 2 deletions(-)
>>
>> diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c
>> index ff89ab5..9602fb2 100644
>> --- a/src/qemu/qemu_migration.c
>> +++ b/src/qemu/qemu_migration.c
>> @@ -4012,6 +4012,7 @@ static void qemuMigrationIOFunc(void *arg)
>>  if (virStreamFinish(data->st) < 0)
>>  goto error;
>>
>> +VIR_FORCE_CLOSE(data->sock);
>>  VIR_FREE(buffer);
>>
>>  return;
>> @@ -4029,7 +4030,11 @@ static void qemuMigrationIOFunc(void *arg)
>>  }
>>
>>   error:
>> -virCopyLastError(>err);
>> +/* Let the source qemu know that the transfer cant continue anymore.
>> + * Don't copy the error for EPIPE as destination has the actual 
>> error. */
>> +VIR_FORCE_CLOSE(data->sock);
>> +if (!virLastErrorIsSystemErrno(EPIPE))
>> +virCopyLastError(>err);
>>  virResetLastError();
>>  VIR_FREE(buffer);
>>  }
>> @@ -4397,7 +4402,6 @@ qemuMigrationRun(virQEMUDriverPtr driver,
>>  if (iothread && qemuMigrationStopTunnel(iothread, ret < 0) < 0)
>>  ret = -1;
>>  }
>> -VIR_FORCE_CLOSE(fd);
>
> ^^^
>
> This causes Coverity to claim a RESOURCE_LEAK
>
> Feels like this was a mistake edit...
>

 The VIR_FORCE_CLOSE() inside qemuMigrationIOFunc() alone is sufficient.
 Having this again here would lead to Warning in the logs. I too thought 
 coverity
 would complain. Is there a way to force ignore a coverity warning?

>>>
>>> Typically a marker of sorts, such as
>>>
>>> /* coverity[leaked_handle]  */
>>>
>>> Although I'm not sure that's the best way to handle this either.
>>>
>>> The problem I see though is this is an "error path" issue and when
>>> perhaps it's safe/required to close fd/io->sock/data->sock.
>>>
>>> Your commit comment notes that the issue is seen on a fairly specific
>>> event (virStreamSend failure) for a specific type of migration.
>>
>> I believe the failure can be seen for all types of migration with savestate
>> mismatch.
>>
>
> My thoughts were based mostly on your commit message comments:
>
> "The qemuMigrationIOFunc() notices the stream being broken from
> virStreamSend() and it cleans up the stream alone. The
> qemuMigrationWaitForCompletion() would never get to 100% transfer
> completion."
>
> and the belief that the core issue you described

Re: [libvirt] [PATCH 0/4] improve virConnectListAllInterfaces()

2015-09-28 Thread Daniel P. Berrange 
On Fri, Sep 25, 2015 at 01:48:41PM -0400, Laine Stump wrote:
> On 09/25/2015 01:27 PM, Daniel P. Berrange wrote:
> >On Fri, Sep 25, 2015 at 05:22:30PM +0100, Daniel P. Berrange wrote:
> >>On Fri, Sep 25, 2015 at 11:13:52AM -0400, Laine Stump wrote:
> >>>There's a bit of background about this here:
> >>>
> >>>https://www.redhat.com/archives/augeas-devel/2015-September/msg1.html
> >>>
> >>>In short, virt-manager is calling the virInterface APIs and that ties
> >>>up a libvirt thread (and CPU core) for a very long time on hosts that
> >>>have a large number of interfaces. These patches don't cure the
> >>>problem (I don't know that there really is a cure other than "Don't DO
> >>>that!"), but they do fix a couple of bugs I found while investigating,
> >>>and make a substantial improvement in the amount of time used by
> >>>virConnectListAllInterfaces().
> >>>
> >>>One thing that I wondered about while investigating this - a big use
> >>>of CPU by virConnectListAllInterfaces() comes from the need to
> >>>retrieve the MAC address of every interface. The MAC addresses are
> >>>both
> >>>
> >>>1) returned to the caller in the interface objects and
> >>>
> >>>2) sent to the policykit ACL checking to decide which interfaces to 
> >>>include in
> >>>the list.
> >>>
> >>>I'm 90% confident that
> >>>
> >>>1) most callers don't really care that they're getting the MAC address
> >>>along with interface name (virt-manager, for example, follows up with
> >>>a virInterfaceGetXMLDesc() anyway)), and
> >>>
> >>>2) there is not even a single host *anywhere* that is using libvirt
> >>>policykit ACLs to limit the list of host interfaces viewable by a
> >>>client.
> >>>
> >>>So we could add a flag to not return MAC addresses, which would allow
> >>>cutting down the time to list all devices to something < 1
> >>>second). But this would be at the expense of no longer having the
> >>>possibility to limit the list with policykit according to MAC
> >>>address. Since all host interface information is available to all
> >>>users via the file system, for example, I don't see this as a huge
> >>>issue, but it would change behavior, so I don't feel comfortable doing
> >>>it. I don't like the idea of a single API call taking > 1 minute to
> >>>return either, though. Does anyone have an opinion about this?
> >>Ultimately 500 interfaces, each ifcfg-XXX file 300 bytes in size
> >>on average is only 150 KB of data. Given the amount of data we
> >>are consuming, here I think it is reasonable to expect we can
> >>process than in a tiny fraction of a second. So there's clearly
> >>a serious algorithmic / data structure flaw here if its taking
> >>minutes.
> >>
> >>By the sounds of the thread you quote, its in augeas itself, so I
> >>think we really need to focus on addressing that root cause as a
> >>priority rather than try to work around it.
> >>
> >>As a side note, we might consider adding new API to netcf so that
> >>we can fetch the entire interface set + macs in one api call to
> >>netcf, though I doubt it'd chance performance that much.
> >So, I instrumented the netcf and augeas code to checking timings.
> 
> What did you use? I tried using perf and oprofile, but all I could get them
> to tell me was that a ton of time was being spent in strcmp(), so either it
> couldn't figure out who was the caller due to missing stack frame pointers,
> or I just didn't know the right commandline options. (The last time I did
> any serious profiling I used some custom code (written by someone else at a
> previous employer) that massaged xml format output from oprofile. A lot has
> changed since then.)

When I said "instrumented" what I mean is that I put gettimeofday()
calls either side of the function calls I thought were interesting/
suspicious, and then printf() the delta :-)

> >The aug_get calls time less than a millisecond, as do the various
> >other calls. I found the bulk of the time is actually coming from
> >the netcf function "get_augeas", which in turns call "aug_load"
> >for every single damn netcf function call.
> 
> I remember David Lutterkort talking about exactly that problem several years
> ago and *thought* I remembered that he had put something into augeas to only
> reread the files if they had changed. Has my memory failed me again? Or is
> augeas doing something and netcf just isn't taking advantage of it?
> 
> >Either we need to stop loading congfig files on every fnuction
> >call in netcf, or we need to add a netcf bulk data API call,
> >so that libvirt can load /all/ the data it needs in 1 single
> >API call.
> 
> I much prefer (1) :-)

The main difficulty with doing (1) is that IIRC, the libvirtd daemon
holds is augeas connection open permanently, so we do need some way
to periodically refresh the interface data. We can't just do it when
a client calls virCOnnectOpen, because apps like openstack one a
single connection and then keep it open forever. I guess doing it on
every function call was the easy way to "solve" this.

Re: [libvirt] Use of 'detach' flag with QMP command `migrate` in qemuMonitorJSONMigrate()

2015-09-28 Thread Daniel P. Berrange 
On Sun, Sep 27, 2015 at 06:23:15PM +0200, Kashyap Chamarthy wrote:
> The qmp-commands.hx file from QEMU says[1]:
> 
> "The user Monitor's "detach" argument is invalid in QMP and should
> not be used"

That does not exactly reflect reality. The QMP parser permits
"detach", but the qmp_migrate() method ignores it, and operates
as if it were always set to 'true', which is what libvirt
wants anyway.

> However, when live block migration is performed, I still see that
> libvirt sets the 'detach' boolean to 'true':
> 
> [. . .]
> 2015-04-09 11:20:54.160+: 12152: debug : 
> qemuMonitorJSONCommandWithFd:290 : Send command 
> '{"execute":"migrate","arguments":{"detach":true,"blk":true,"inc":false,"uri":"fd:migrate"},"id":"libvirt-18"}'
>  for write with FD -1
> [. . .]
> 
> Where 'detach' means: "not wait for completion" (reading hmp-commands.hx
> in QEMU source) or 'QEMU_MONITOR_MIGRATE_BACKGROUND' (reading
> qemuMonitorJSONMigrate() from qemu_monitor_json.c in libvirt source).
> 
> 
> Two questions:
> 
>   - Should the 'detach' flag be not passed in this case, because the
> documentation says it's not valid in QMP case?
> 
>   - _What_ exactly is setting the 'detach' flag explicitly in this case?
> Or is it default when using 'inc' flag ('--copy-storage-inc' in
> `virsh` parlance)?

In HMP, the monitor would block until migration was completed. Passing
detach=true means the monitor command completes immediately migration
has started. Libvirt passes detach=true because it wants the latter
behaviour which was not the default with HMP. We've just inherited
that when we ported to QMP, even though it is redundant.

> 
> Contextual libvirtd.log from source, with log_filter for 'qemu' set[2].
> 
> Note that in the above case, live block migration _did_ succeed, I'm
> just asking this to educate myself.
> 
> 
> PS: If you're wondering why am I not using the new 'drive-mirror' based
> approach above, I performed this block migration via OpenStack Nova.
> Currently in Nova's case, live block migration falls back to the old
> approach of QMP `migrate` command (with 'inc' flag set to true -- it
> explicitly set by OpenStack Nova) via  qemuMonitorJsonMigrate(), and
> not the new way of qemuMonitorJSONDriveMirror().
> 
> 
> I was testing with:
> 
>   - libvirt-daemon-driver-qemu-1.2.13.1-2.fc22.x86_64
>   - qemu-system-x86-2.3.1-1.fc22.x86_64
> 
> [1] http://git.qemu.org/?p=qemu.git;a=blob;f=qmp-commands.hx#l643
> [2] 
> https://kashyapc.fedorapeople.org/virt/temp/live-blk-migration-libvirt-debug-log-on-src.txt

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] Use of 'detach' flag with QMP command `migrate` in qemuMonitorJSONMigrate()

2015-09-28 Thread Kashyap Chamarthy 
On Mon, Sep 28, 2015 at 10:02:48AM +0100, Daniel P. Berrange wrote:
> On Sun, Sep 27, 2015 at 06:23:15PM +0200, Kashyap Chamarthy wrote:
> > The qmp-commands.hx file from QEMU says[1]:
> > 
> > "The user Monitor's "detach" argument is invalid in QMP and should
> > not be used"
> 
> That does not exactly reflect reality. 

Ah, so the doc should probably be reworded.

> The QMP parser permits "detach", but the qmp_migrate() method ignores
> it, and operates as if it were always set to 'true', which is what
> libvirt wants anyway.

I see.  Indeed, the qmp_migrate() method in QEMU explicitly checks if
'blk' and 'inc' flags are initialized, but ignores 'detach'.

> > However, when live block migration is performed, I still see that
> > libvirt sets the 'detach' boolean to 'true':

[. . .]

> > Where 'detach' means: "not wait for completion" (reading hmp-commands.hx
> > in QEMU source) or 'QEMU_MONITOR_MIGRATE_BACKGROUND' (reading
> > qemuMonitorJSONMigrate() from qemu_monitor_json.c in libvirt source).
> > 
> > 
> > Two questions:
> > 
> >   - Should the 'detach' flag be not passed in this case, because the
> > documentation says it's not valid in QMP case?
> > 
> >   - _What_ exactly is setting the 'detach' flag explicitly in this case?
> > Or is it default when using 'inc' flag ('--copy-storage-inc' in
> > `virsh` parlance)?
> 
> In HMP, the monitor would block until migration was completed.

Yep, I see so in hmp.c (in QEMU source), 'detach' defaults to
false.

> Passing detach=true means the monitor command completes immediately
> migration has started. Libvirt passes detach=true because it wants the
> latter behaviour which was not the default with HMP.

> We've just inherited that when we ported to QMP, even though it is
> redundant.

Noted, thanks for the clarification, Dan.

[. . .]

-- 
/kashyap

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [libvirt-test-API] [PATCH] Add two cases for API interfaceAddresses and make small changes to global.cfg

2015-09-28 Thread Shanzhi Yu 
Signed-off-by: Shanzhi Yu 
---
 cases/linux_domain.conf| 12 +++
 global.cfg |  8 +++--
 repos/domain/get_guest_network_info.py | 66 ++
 3 files changed, 84 insertions(+), 2 deletions(-)
 create mode 100644 repos/domain/get_guest_network_info.py

diff --git a/cases/linux_domain.conf b/cases/linux_domain.conf
index 8440c61..5b216f9 100644
--- a/cases/linux_domain.conf
+++ b/cases/linux_domain.conf
@@ -66,6 +66,18 @@ domain:set_guest_time
 flags
 sync
 
+domain:get_guest_network_info
+guestname
+$defaultname
+flags
+lease
+
+domain:get_guest_network_info
+guestname
+$defaultname
+flags
+agent
+
 virconn:connection_getAllDomainStats
 stats
 state|cpu|balloon|vcpu|interface|block
diff --git a/global.cfg b/global.cfg
index 56677a5..1b72119 100644
--- a/global.cfg
+++ b/global.cfg
@@ -44,6 +44,8 @@ rhel6u1_i386 = http://
 rhel6u1_x86_64 = http://
 rhel6u2_i386 = http://
 rhel6u2_x86_64 = http://
+rhel7u1_x86_64 = http://
+rhel7u2_x86_64 = http://
 fedora12_i386 = http://
 fedora12_x86_64 = http://
 win2008_i386 = http://
@@ -70,6 +72,8 @@ rhel6_i386_http_ks = http://
 rhel6_x86_64_http_ks = http://
 rhel6u2_i386_http_ks = http://
 rhel6u2_x86_64_http_ks = kickstart.cfg
+rhel7u1_x86_64_http_ks = http://
+rhel7u2_x86_64_http_ks = http://
 fedora12_i386_http_ks = http://
 fedora12_x86_64_http_ks = http://
 
@@ -97,7 +101,7 @@ sourcepath = /media/share
 # also exercise DNS resolution
 #
 [other]
-wget_url = http://
+wget_url = http://libvirt.org/index.html
 
 #
 # The variables section is a set of variables used by the
@@ -127,7 +131,7 @@ defaulthv = kvm
 defaultname = libvirt_test_api
 # default os version to use for installing a new guest
 # the value of it is the first part of 'rhel6u2_x86_64' in [guest] section 
above
-defaultos = rhel6u2
+defaultos = rhel7u2
 # default architecture to use for installing a new guest
 defaultarch = x86_64
 # default the number of vcpu to use for defining or installing a guest
diff --git a/repos/domain/get_guest_network_info.py 
b/repos/domain/get_guest_network_info.py
new file mode 100644
index 000..35bba3b
--- /dev/null
+++ b/repos/domain/get_guest_network_info.py
@@ -0,0 +1,66 @@
+#!/usr/bin/python
+
+import libvirt
+from libvirt import libvirtError
+from src import sharedmod
+
+required_params = ('guestname', 'flags',)
+optional_params = {}
+
+def check_guest_status(domobj):
+"""check guest current status
+"""
+state = domobj.info()[0]
+if state == libvirt.VIR_DOMAIN_SHUTOFF or \
+state == libvirt.VIR_DOMAIN_SHUTDOWN:
+return False
+else:
+return True
+
+def get_guest_network_info(params):
+"""get guest network interface info
+"""
+
+logger = params['logger']
+guestname = params['guestname']
+flags = params['flags']
+
+conn = sharedmod.libvirtobj['conn']
+
+domobj = conn.lookupByName(guestname)
+
+flags = params['flags']
+logger.info("The flags are %s" % flags)
+flags_string = flags.split("|")
+flags = 0
+
+for flag in flags_string:
+if flag  == 'lease':
+flags |= libvirt.VIR_DOMAIN_INTERFACE_ADDRESSES_SRC_LEASE
+elif flag == 'agent':
+flags |= libvirt.VIR_DOMAIN_INTERFACE_ADDRESSES_SRC_AGENT
+else:
+logger.error("unknow flags")
+return 1
+
+logger.info("the given flags is %d" % flags)
+
+# Check domain status
+if check_guest_status(domobj):
+logger.info("Guest is running")
+else:
+logger.error("Guest is shut off status")
+return 1
+
+try:
+info = domobj.interfaceAddresses(flags)
+logger.info("get guest interface info")
+
+except libvirtError, e:
+logger.error("API error message: %s, error code is %s" \
+% (e.message, e.get_error_code()))
+return 1
+
+return 0
+
+
-- 
1.8.3.1

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [libvirt-test-API] [PATCH] fix two error in script pin_iothread.py and connection_getAllDomainStats.py

2015-09-28 Thread Shanzhi Yu 
Signed-off-by: Shanzhi Yu 
---
 repos/domain/pin_iothread.py  | 2 +-
 repos/virconn/connection_getAllDomainStats.py | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/repos/domain/pin_iothread.py b/repos/domain/pin_iothread.py
index 28ee2c4..d2d812f 100644
--- a/repos/domain/pin_iothread.py
+++ b/repos/domain/pin_iothread.py
@@ -116,7 +116,7 @@ def pin_iothread(params):
 
 if not find_iothreadid_fromxml(vm, 1, 1):
 logger.info("add iothread %d to running guest" % 1)
-vm.addIOThread(i, libvirt.VIR_DOMAIN_AFFECT_LIVE)
+vm.addIOThread(1, libvirt.VIR_DOMAIN_AFFECT_LIVE)
 
 vm.pinIOThread(1, tu_cpu, libvirt.VIR_DOMAIN_AFFECT_LIVE)
 cpuset = find_iothreadpin_fromxml(vm, 1, 1)
diff --git a/repos/virconn/connection_getAllDomainStats.py 
b/repos/virconn/connection_getAllDomainStats.py
index d95004f..3362444 100644
--- a/repos/virconn/connection_getAllDomainStats.py
+++ b/repos/virconn/connection_getAllDomainStats.py
@@ -164,7 +164,7 @@ def check_each_vcpu(logger,dom_name,dom_active,dom_eles):
 if not vcpu_cur:
 for i in range(0,vcpu_max):
 vcpu_pre = "vcpu."+ str(i) + "."
-logger.debug("Checking %sstate: %d" \
+logger.debug("Checking %sstate: %s" \
 %(vcpu_pre, dom_eles.get(vcpu_pre + "state")))
 if not compare_value(logger,vcpu_stat, \
 dom_eles.get(vcpu_pre + "state")):
@@ -172,7 +172,7 @@ def check_each_vcpu(logger,dom_name,dom_active,dom_eles):
 elif int(vcpu_cur.nodeValue) <= vcpu_max:
 for i in range(0,int(vcpu_cur.nodeValue)):
 vcpu_pre = "vcpu."+ str(i) + "."
-logger.debug("Checking %sstate: %d" \
+logger.debug("Checking %sstate: %s" \
 %(vcpu_pre, dom_eles.get(vcpu_pre + "state")))
 if not compare_value(logger,vcpu_stat, \
 dom_eles.get(vcpu_pre + "state")):
-- 
1.8.3.1

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [libvirt-test-API] [PATCH] change some cases order in conf file linux_domain.conf

2015-09-28 Thread Shanzhi Yu 
Some cases need guest agent running in domain, change some cases order
to avoid the failure.

Signed-off-by: Shanzhi Yu 
---
 cases/linux_domain.conf | 100 
 1 file changed, 50 insertions(+), 50 deletions(-)

diff --git a/cases/linux_domain.conf b/cases/linux_domain.conf
index 5b216f9..6315613 100644
--- a/cases/linux_domain.conf
+++ b/cases/linux_domain.conf
@@ -78,6 +78,56 @@ domain:get_guest_network_info
 flags
 agent
 
+domain:domain_fsfreeze
+guestname
+$defaultname
+
+domain:domain_fsthaw
+guestname
+$defaultname
+
+domain:domain_fsfreeze
+guestname
+$defaultname
+mountpoint
+/
+
+domain:domain_fsthaw
+guestname
+$defaultname
+
+domain:fsinfo
+guestname
+$defaultname
+username
+$username
+userpassword
+$password
+conn
+qemu:///system
+
+domain:set_user_passwd
+guestname
+$defaultname
+username
+$username
+userpassword
+$password
+conn
+qemu:///system
+
+domain:set_user_passwd
+guestname
+$defaultname
+username
+$username
+userpassword
+$password
+conn
+qemu:///system
+flags
+encrypted
+
 virconn:connection_getAllDomainStats
 stats
 state|cpu|balloon|vcpu|interface|block
@@ -259,24 +309,6 @@ domain:open_graphicsfd
 flags
skipauth
 
-domain:domain_fsfreeze
-guestname
-$defaultname
-
-domain:domain_fsthaw
-guestname
-$defaultname
-
-domain:domain_fsfreeze
-guestname
-$defaultname
-mountpoint
-/
-
-domain:domain_fsthaw
-guestname
-$defaultname
-
 virconn:connection_security_model
 guestname
 $defaultname
@@ -311,38 +343,6 @@ domain:info_iothread
 conn
 qemu:///system
 
-domain:fsinfo
-guestname
-$defaultname
-username
-$username
-userpassword
-$password
-conn
-qemu:///system
-
-domain:set_user_passwd
-guestname
-$defaultname
-username
-$username
-userpassword
-$password
-conn
-qemu:///system
-
-domain:set_user_passwd
-guestname
-$defaultname
-username
-$username
-userpassword
-$password
-conn
-qemu:///system
-flags
-encrypted
-
 domain:destroy
 guestname
 $defaultname
-- 
1.8.3.1

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH] qemu: Fix dynamic_ownership qemu.conf setting

2015-09-28 Thread Cole Robinson 
Commit 307fb904 (Sep 10) added a 'privileged' variable when creating
the DAC driver:

@@ -153,6 +157,7 @@ virSecurityManagerNewDAC(const char *virtDriver,
  bool defaultConfined,
  bool requireConfined,
  bool dynamicOwnership,
+ bool privileged,
  virSecurityManagerDACChownCallback chownCallback)

But argument order is mixed up at the caller, swapping dynamicOwnership
and privileged values. This corrects the argument order

https://bugzilla.redhat.com/show_bug.cgi?id=1266628
---
 src/qemu/qemu_driver.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index 7025c51..aff1915 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -431,8 +431,8 @@ qemuSecurityInit(virQEMUDriverPtr driver)
  cfg->allowDiskFormatProbing,
  cfg->securityDefaultConfined,
  cfg->securityRequireConfined,
- virQEMUDriverIsPrivileged(driver),
  cfg->dynamicOwnership,
+ virQEMUDriverIsPrivileged(driver),
  qemuSecurityChownCallback)))
 goto error;
 if (!stack) {
-- 
2.5.0

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list