date:20100727

Re: [libvirt] [Qemu-devel] Re: [PATCH] Introduce a -libvirt-caps flag as a stop-gap

2010-07-27 Thread Avi Kivity


 On 07/27/2010 07:38 PM, Anthony Liguori wrote:
I'm going to revert the -help changes for 0.13 so that old versions of 
libvirt work but not for master.


What is the goal here?   Make qemu.git explicitly be unusable via libvirt?

--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

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

Re: [libvirt] [PATCH] lxc: Fix return value handlings of vethInterfaceUpOrDown and moveInterfaceToNetNs

2010-07-27 Thread Laine Stump


 On 07/27/2010 11:11 AM, Ryota Ozaki wrote:

On Mon, Jul 26, 2010 at 11:37 PM, Laine Stump  wrote:

  On 07/26/2010 08:31 AM, Ryota Ozaki wrote:

On Mon, Jul 26, 2010 at 6:51 PM, Daniel P. Berrange
  wrote:

You could just change

   return cmdResult

to

   return -cmdResult;

That would still let you give the error code, while also keeping the
value
<0

It looks better than mine ;-) I'll rewrite my patch in such a way.

Laine, is it ok for you too?


Doing that is fine when all possible failures in the function have an
associated errno. In the case of virRun'ing an external program that could
return a non-zero exit code, this is unfortunately not the case, so those
functions that call virRun will need to report the error themselves and
return -1.

For veth.c all functions match the latter case while bridge.c has both.
If we don't take care about the consistency between veth.c and bridge.c,
we can focus on how to treat the latter case. (Ideally keeping the consistency
is better, but it seems difficult...)


We can ignore bridge.c for now - there is a lot of code in libvirt that 
doesn't follow the "-errno on failure" convention, so we should try to 
be as narrow as possible. For this cleanup, I like the scope of just 
veth.c and its direct callers.


Another thing I didn't notice when I wrote my first comment on this 
thread is that most of the error conditions in the involved functions 
are due to an external program failing, which will likely be due to the 
program returning a non-0 code. However, that's not *always* the case, 
so we can't really say that the function will always return a valid 
"-exitcode", nor can we say it will always return a valid "-errno" (and 
as you point out, they can conflict).




When non-0 exits from the called program are all failures, the simplest way
to do it is, as you say, to just not pass a pointer to a resultcode to
virRun (as long as the error message reported by virRun is useful enough -

Yes.


remember that it gives the name of the program being run, and "virRun", but
not the name of the calling function).

Agreed. That'll lose useful information for debugging. One option is
to re-report
an error in the calling function. It will lead reporting two messages,
but it should
be more useful than less reports.

One concern aobut virRun's error reporting is that it shows standard
errors through
DEBUG so by default it shows nothing while they are important for ifconfig
and ip commands because their error messages may be according to errno.


I also recall once in some other code letting virRun display the error 
and the result was that someone else who got the error (which was really 
unimportant) was handed a giant scary looking (and uninformative) error 
message that took their attention away from the real problem, which was 
elsewhere (I forget the details now, but you get the idea). It's 
convenient, but if you want meaningful errors, I would recommend against 
letting virRun report them.


I went through all the calls to all the functions listed in veth.h, and 
I see that they are called from relatively few places, and the error 
logs are almost always to the veth.c function that's being called, not 
to the caller. So I think it could work to have:


1) all calls to virRun in veth.c request cmdResult.

2) all functions in veth.c log the errors themselves (with one possible 
exception - vethDelete() - because it is often called during error 
recovery).


3) all functions in veth.c return -1 to their caller

4) all functions called by those functions also return -1 (this is 
mostly the case already, once you change veth.c, and has no effect on 
those functions' callers).


Logging errors in veth.c functions you have all the information you need 
from virRun, but also know the context in which the program is being 
called (see my notes below) so you can avoid the "always big and scary" 
messages from virRun, and you can consistently return -1.


(The only downside is that you don't have access to the stderr of the 
executed program, but that will be solved when we switch to Dan 
Berrange's new exec library ;-)


Does this sound reasonable and doable? If you agree with it, but think 
it's not doable in time for the release on Friday, but the original bug 
has real consequences (ie it makes something potentially fail), then I 
think it would be okay to push your original patch, with intent to do a 
further cleanup after the release.


(sorry for turning this 2 line bugfix into an odyssey of refactoring - 
I'm just paying it forward ;-)


*
Here are my notes from looking at the functions in veth.c and their callers:

vethCreate

   called from:
lxcSetupInterfaces - on error, it logs "Failed to create device 
pair %d", rc


   solution - log that error in vethCreate, and have vethCreate return 
-1 on failure


vethDelete

   called from:
 lxcControllerCleanupInterfaces - logs, but doesn't display code
 lxcVmCleanup - ignores

[libvirt] Extensions to the libvirt Storage API

2010-07-27 Thread Patrick Dignan


Hi Everyone,

I'm looking at implementing some functionality in libvirt that would 
allow it to call functions in an unpublished iSCSI library.  Some of the 
functionality I wish to implement is not currently part of the libvirt 
storage API.  I wanted to suggest the following additions to the storage 
API: grow volumes, show whether thin provisioning is enabled, enable 
thin provisioning, disable thin provisioning, create snapshots, and 
delete snapshots.  I've added a patch at the end of the mail showing how 
I think these functions should be implemented.  Note that I have not 
included details about the virStorageSnapshotDefPtr yet, that's the next 
step.


Perhaps this should be in a separate mail for better threading, but it 
seems a bit strange to me that the storage interface isn't pluggable in 
the traditional sense.  In order to add a backend to libvirt, one has to 
make modifications all over the place, for example: virt-inst, the 
Makefile.am, the configure.ac, storage_backend.h, and several other 
places.  It would make sense to me to make this pluggable such that 
someone could just load in a library that implements the required 
functions and some identifying information (eg type of storage, 
description, etc).  A list of supported backends could be stored in 
empty files in a directory somewhere, or some similar hack.  This way 
someone could write a plugin for tgtd for example, or in my case the 
library I'm working with.  I think this would also help others with 
writing plugins for more storage backends.  How difficult do you think 
this would be?  I'm willing to do a reasonable amount of work to get 
this implemented, but I want to know what the experts think!


Best,

Patrick Dignan

--- libvirt-0.8.2.orig/src/storage/storage_backend.h2010-06-16 
17:27:22.0 -0500
+++ libvirt-0.8.2.work/src/storage/storage_backend.h2010-07-27 
16:36:08.321439851 -0500

@@ -43,6 +43,13 @@
 typedef int (*virStorageBackendBuildVolFrom)(virConnectPtr conn, 
virStoragePoolObjPtr pool,
  virStorageVolDefPtr 
origvol, virStorageVolDefPtr newvol,

  unsigned int flags);
+typedef int (*virStorageBackendGrowVol)(virConnectPtr conn, 
virStoragePoolObjPtr pool, virStorageVolDefPtr vol, unsigned long long 
newsize);
+typedef bool (*virStorageBackendThinProvisionShow)(virConnectPtr conn, 
virStoragePoolObjPtr pool, virStorageVolDefPtr vol);
+typedef int (*virStorageBackendThinProvisionEnable)(virConnectPtr conn, 
virStoragePoolObjPtr pool, virStorageVolDefPtr vol);
+typedef int (*virStorageBackendThinProvisionDisable)(virConnectPtr 
conn, virStoragePoolObjPtr pool, virStorageVolDefPtr vol);

+
+typedef int (virStorageBackendCreateSnapshot)(virConnectPtr conn, 
virStoragePoolObjPtr pool, virStorageVolDefPtr vol, 
virStorageSnapshotDefPtr snapshot);
+typedef int (virStorageBackendDeleteSnapshot)(virConnectPtr conn, 
virStoragePoolObjPtr pool, virStorageVolDefPtr vol, 
virStorageSnapshotDefPtr snapshot);


 /* File creation/cloning functions used for cloning between backends */
 int virStorageBackendCreateRaw(virConnectPtr conn,
@@ -76,6 +83,12 @@
 virStorageBackendCreateVol createVol;
 virStorageBackendRefreshVol refreshVol;
 virStorageBackendDeleteVol deleteVol;
+virStorageBackendGrowVol growVol;
+virStorageBackendThinProvisionShow thinProvisionShow;
+virStorageBackendThinProvisionEnable thinProvisionEnable;
+virStorageBackendThinProvisionDisable thinProvisionDisable;
+virStorageBackendCreateSnapshot createSnapshot;
+virStorageBackendDeleteSnapshot deleteSnapshot;
 };

 virStorageBackendPtr virStorageBackendForType(int type);

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

Re: [libvirt] [PATCH] qemu: Allow setting boot menu on/off

2010-07-27 Thread Cole Robinson

On 07/27/2010 08:59 AM, Daniel Veillard wrote:
> On Tue, Jul 27, 2010 at 08:48:07AM -0400, Cole Robinson wrote:
>> On 07/27/2010 06:13 AM, Daniel P. Berrange wrote:
>>> On Mon, Jul 26, 2010 at 04:31:23PM -0400, Cole Robinson wrote:
 Add a new element to the  block:

   

 Which maps to -boot,menu=on|off on the QEMU command line.

 I decided to use an explicit 'enable' attribute rather than just make the
 bootmenu element boolean. This allows us to treat lack of a bootmenu 
 element
 as 'use hypervisor default'.

 Signed-off-by: Cole Robinson 
>>>
>>> I'm wondering what we should do if we need a further option
>>> to turn on/off the PXE boot menus that SEABIOS now adds to
>>> QEMU for each NIC. I guess that might be a separate 
>>>  element within the  device so probably
>>> wouldn't impact this modelling
>>>
>>
>> Yeah, I think we eventually need some sort of  element at the
>> device level anyways, to support booting off hdb instead of hda for
>> example. But yeah, I don't think it should affect this patch.
> 
>   Agreed, ACK,
> 

Thanks, pushed now.

- Cole

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

Re: [libvirt] [PATCH] qemu: Error on unsupported graphics config

2010-07-27 Thread Cole Robinson

On 07/27/2010 06:09 AM, Daniel P. Berrange wrote:
> On Mon, Jul 26, 2010 at 04:31:21PM -0400, Cole Robinson wrote:
>> Throw an explicit error if multiple graphics devices are specified, or
>> an unsupported type is specified (rdp).
>>
>> Signed-off-by: Cole Robinson 
>> ---
>>  src/qemu/qemu_conf.c |   12 
>>  1 files changed, 12 insertions(+), 0 deletions(-)
>>
>> diff --git a/src/qemu/qemu_conf.c b/src/qemu/qemu_conf.c
>> index 0dbab48..05ad67d 100644
>> --- a/src/qemu/qemu_conf.c
>> +++ b/src/qemu/qemu_conf.c
>> @@ -4542,6 +4542,12 @@ int qemudBuildCommandLine(virConnectPtr conn,
>>  }
>>  }
>>  
>> +if (def->ngraphics > 1) {
>> +qemuReportError(VIR_ERR_INTERNAL_ERROR,
>> +"%s", _("only 1 graphics device is supported"));
>> +goto error;
>> +}
>> +
>>  if ((def->ngraphics == 1) &&
>>  def->graphics[0]->type == VIR_DOMAIN_GRAPHICS_TYPE_VNC) {
>>  virBuffer opt = VIR_BUFFER_INITIALIZER;
>> @@ -4641,6 +4647,12 @@ int qemudBuildCommandLine(virConnectPtr conn,
>>   * default, since the default changes :-( */
>>  if (qemuCmdFlags & QEMUD_CMD_FLAG_SDL)
>>  ADD_ARG_LIT("-sdl");
>> +
>> +} else if ((def->ngraphics == 1)) {
>> +qemuReportError(VIR_ERR_INTERNAL_ERROR,
>> +_("unsupported graphics type '%s'"),
>> +virDomainGraphicsTypeToString(def->graphics[0]->type));
>> +goto error;
>>  }
>>  
>>  if (def->nvideos) {
> 
> ACK
> 
> Daniel

Thanks, pushed.

- Cole

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

Re: [libvirt] [PATCH] docs: Link wiki FAQ to main page

2010-07-27 Thread Cole Robinson

On 07/27/2010 06:09 AM, Daniel P. Berrange wrote:
> On Mon, Jul 26, 2010 at 04:31:22PM -0400, Cole Robinson wrote:
>> Since DV recommended keeping the build instructions distributed with the
>> source, move them from the old FAQ to the downloads page.
>>
>> Signed-off-by: Cole Robinson 
>> ---
>>  docs/FAQ.html.in   |  144 
>> 
>>  docs/Makefile.am   |3 +-
>>  docs/downloads.html.in |   29 ++
>>  docs/search.php|2 +-
>>  docs/sitemap.html.in   |2 +-
>>  5 files changed, 32 insertions(+), 148 deletions(-)
>>  delete mode 100644 docs/FAQ.html.in
> 
> 
> ACK
> 

Thanks, pushed.

- Cole

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

[libvirt] [PATCH 1/3] libvirt-guests: detect invalid arguments

2010-07-27 Thread Eric Blake

Reject extra arguments.
Return the correct status for unknown arguments, as mandated by
https://fedoraproject.org/wiki/Packaging/SysVInitScript
Add --help, as a permitted extension.

* daemon/libvirt-guests.init.in (usage): New function.  Use it in
more places, and return correct value.
---
 daemon/libvirt-guests.init.in |   16 ++--
 1 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/daemon/libvirt-guests.init.in b/daemon/libvirt-guests.init.in
index d2ec96a..3a5b205 100644
--- a/daemon/libvirt-guests.init.in
+++ b/daemon/libvirt-guests.init.in
@@ -282,8 +282,21 @@ gueststatus() {
 done
 }

+# usage [val]
+# Display usage string, then exit with VAL (defaults to 2).
+usage() {
+echo $"Usage: $0 {start|stop|restart|force-reload|gueststatus|shutdown}"
+exit ${1-2}
+}
+
 # See how we were called.
+if test $# != 1; then
+usage
+fi
 case "$1" in
+--help)
+usage 0
+;;
 start|stop|gueststatus)
 $1
 ;;
@@ -304,8 +317,7 @@ case "$1" in
 stop
 ;;
 *)
-echo $"Usage: $0 
{start|stop|restart|force-reload|gueststatus|shutdown}"
-exit 3
+usage
 ;;
 esac
 exit $RETVAL
-- 
1.7.2

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

[libvirt] [PATCH 2/3] libvirt-guests: enhance status

2010-07-27 Thread Eric Blake

LSB and https://fedoraproject.org/wiki/Packaging/SysVInitScript
require status to output something useful, rather than just use
the exit code.

* daemon/libvirt-guests.init.in (status): Break into new routine,
and provide output.
(usage): Document status.
---
 daemon/libvirt-guests.init.in |   26 --
 1 files changed, 20 insertions(+), 6 deletions(-)

diff --git a/daemon/libvirt-guests.init.in b/daemon/libvirt-guests.init.in
index 3a5b205..953b18a 100644
--- a/daemon/libvirt-guests.init.in
+++ b/daemon/libvirt-guests.init.in
@@ -282,2 +282,2 @@ gueststatus() {
 done
 }

+# rh_status
+# Display current status: whether saved state exists, and whether start
+# has been executed.  We cannot use status() from the functions library,
+# since there is no external daemon process matching this init script.
+rh_status() {
+if [ -f "$LISTFILE" ]; then
+echo $"stopped, with saved guests"
+RETVAL=3
+else
+if [ -f "$VAR_SUBSYS_LIBVIRT_GUESTS" ]; then
+echo $"started"
+else
+echo $"stopped, with no saved guests"
+fi
+RETVAL=0
+fi
+}
+
 # usage [val]
 # Display usage string, then exit with VAL (defaults to 2).
 usage() {
-echo $"Usage: $0 {start|stop|restart|force-reload|gueststatus|shutdown}"
+echo $"Usage: $0 
{start|stop|status|restart|force-reload|gueststatus|shutdown}"
 exit ${1-2}
 }

@@ -306,11 +324,7 @@ case "$1" in
 force-reload)
 ;;
 status)
-if [ -f "$LISTFILE" ]; then
-RETVAL=3
-else
-RETVAL=0
-fi
+rh_status
 ;;
 shutdown)
 ON_SHUTDOWN=shutdown
-- 
1.7.2

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

[libvirt] [PATCH 0/3] libvirt-guests: fix init script to Fedora standards

2010-07-27 Thread Eric Blake

https://bugzilla.redhat.com/show_bug.cgi?id=617300 documents
several shortcoming in our libvirt-guests init script, in
relation to Fedora init script standards.  For easier review,
I've split it into three simpler patches.

Eric Blake (3):
  libvirt-guests: detect invalid arguments
  libvirt-guests: enhance status
  libvirt-guests: add reload, condrestart

 daemon/libvirt-guests.init.in |   46 +---
 1 files changed, 38 insertions(+), 8 deletions(-)

-- 
1.7.2

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

[libvirt] [PATCH 3/3] libvirt-guests: add reload, condrestart

2010-07-27 Thread Eric Blake

Optional per LSB, but required by Fedora:
https://fedoraproject.org/wiki/Packaging/SysVInitScript

* daemon/libvirt-guests.init.in (main): Add more required
commands.
---
 daemon/libvirt-guests.init.in |8 ++--
 1 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/daemon/libvirt-guests.init.in b/daemon/libvirt-guests.init.in
index 953b18a..960856c 100644
--- a/daemon/libvirt-guests.init.in
+++ b/daemon/libvirt-guests.init.in
@@ -303,7 +303,7 @@ rh_status() {
 # usage [val]
 # Display usage string, then exit with VAL (defaults to 2).
 usage() {
-echo $"Usage: $0 
{start|stop|status|restart|force-reload|gueststatus|shutdown}"
+echo $"Usage: $0 
{start|stop|status|restart|condrestart|try-restart|reload|force-reload|gueststatus|shutdown}"
 exit ${1-2}
 }

@@ -321,7 +321,11 @@ case "$1" in
 restart)
 stop && start
 ;;
-force-reload)
+condrestart|try-restart)
+[ -f "$VAR_SUBSYS_LIBVIRT_GUESTS" ] && stop && start
+;;
+reload|force-reload)
+# Nothing to do; we reread configuration on each invocation
 ;;
 status)
 rh_status
-- 
1.7.2

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

Re: [libvirt] [PATCH] esx: Add vpx:// scheme to allow direct connection to a vCenter

2010-07-27 Thread Matthias Bolte

2010/7/27 Matthias Bolte :
> 2010/7/26 Daniel P. Berrange :
>> On Mon, Jul 19, 2010 at 01:26:10AM +0200, Matthias Bolte wrote:
>>> Add a pointer to the primary context of a connection and use it in all
>>> driver functions that don't dependent on the context type. This includes
>>> almost all functions that deal with a virDomianPtr. Therefore, using
>>> a vpx:// connection allows you to perform all the usual domain related
>>> actions like start, destroy, suspend, resume, dumpxml etc.
>>>
>>> Some functions that require an explicitly specified ESX server don't work
>>> yet. This includes the host UUID, the hostname, the general node info, the
>>> max vCPU count and the free memory. Also not working yet are migration and
>>> defining new domains.
>>
>>
>> If you're connecting to vpx://example-vcenter.com  how does the driver
>> know which host you're asking for data on ? IIUC a vcenter reports on all
>> hosts in a data center. Does new mode still guarentee that every domain
>> has a unique name & ID, as well as UUID ?
>>
>
> UUID is unique by definition.
>
> The driver parses the ID from the internal object name. As far as I
> understand the object model this ID is unique. But the ID might be
> different if you look at the same guest through a esx:// or vpx://
> connection, but it's unique per connection.
>
> The name is a bit more tricky. For a single ESX server it's unique. I
> thought for a vCenter it's unique per datacenter, because the vCenter
> won't let you define a second guest with an existing name. I just
> played a bit with it and it seems there are ways to define two domains
> with the same name in a single cluster. This is definitely a problem
> and I'm not sure how to fix that, other than using hacks like adding
> the ID to the name.
>
> In order to have a guaranteed unique domain name for a vpx://
> connection the final name will probably have to be build like this
>
>  //-

Actually adding the domain ID should be enough

  -

> Quite ugly and unstable, because it'll change across a migration :(
>
> The same name uniqueness problem exists for datastores, because their
> names are unique per datacenter only.
>
> Matthias
>

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

Re: [libvirt] VMware Workstation/Player support

2010-07-27 Thread Matthias Bolte

2010/7/27 Daniel Veillard :
> On Tue, Jul 27, 2010 at 03:20:42PM +0200, Jean-Baptiste Rouault wrote:
>> Hi all,
>>
>> I'm working on the hynesim project (http://www.hynesim.org
>> http://blog.hynesim.org).
>> We are going to add VMware Workstation support to hynesim,
>> so we would like to contribute to the development of a libvirt driver.
>>
>> There probably are multiple ways of doing this, one of them could
>> be to use the VIX C API provided by VMware :
>> http://www.vmware.com/support/developer/vix-api/
>> However, the VIX license seems to be quite restrictive :
>> http://www.vmware.com/download/eula/vixapi_eula.html
>> I'm not a license expert so I don't know if this license forbids
>> using the API in software like libvirt.
>
>  We had a look at the VIX Licence and it wasn't pretty, this EULA
> seems to directly try to prevent reuse for anything except toying
> with it.

We don't use VIX in the VPX/ESX/GSX driver for that reason either.
Also at the time the driver development started VIX had basic ESX
support since 3 weeks or so.

>  Another big problem is that it's not available for distribution
> not packaged, it's a download from VMWare, i.e. it won't be present
> in any build installation of distribution I think. As a result the
> dependancy will make this impossible to support in default builds,
> the only way being to download the vix library, and then rebuild
> libvirt locally. Very painful !

I didn't realize this problem until now, but it's probably a bigger
problem than the license one.

>> Another possibility could be to run VMware command line tools
>> from libvirt to control guests.
>
>  That sounds quite a better option, first we avoid the licencing
> tie in, second we can have the driver detect at runtime if the command
> line tools are available, and then activate or not the driver. This
> allows to provide the compiled support in all libvirt builds, even
> if only a fraction of the users may actually use VMware Workstation.
>
>  So really it sounds like making the driver call directly the
> command line tools is the right approach.
>  Code wise the driver should be installed in a directory separated
> from src/esx , and some tweaking might be needed to 'export' the
> ESX config parser and make it available from there, but that should
> not be too hard really.
>

We'll need to move the VMX handling code from src/esx to src/util,
because drivers are not allowed to depend on each other.

That should be possible, but will require some refactoring, because
this code is currently closely entangled with the reset of the ESX
driver in some places and parts of it are probably quite ESX specific.

Matthias

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

Re: [libvirt] [PATCH] esx: Add vpx:// scheme to allow direct connection to a vCenter

2010-07-27 Thread Matthias Bolte

2010/7/26 Daniel P. Berrange :
> On Mon, Jul 19, 2010 at 01:26:10AM +0200, Matthias Bolte wrote:
>> Add a pointer to the primary context of a connection and use it in all
>> driver functions that don't dependent on the context type. This includes
>> almost all functions that deal with a virDomianPtr. Therefore, using
>> a vpx:// connection allows you to perform all the usual domain related
>> actions like start, destroy, suspend, resume, dumpxml etc.
>>
>> Some functions that require an explicitly specified ESX server don't work
>> yet. This includes the host UUID, the hostname, the general node info, the
>> max vCPU count and the free memory. Also not working yet are migration and
>> defining new domains.
>
>
> If you're connecting to vpx://example-vcenter.com  how does the driver
> know which host you're asking for data on ? IIUC a vcenter reports on all
> hosts in a data center. Does new mode still guarentee that every domain
> has a unique name & ID, as well as UUID ?
>

UUID is unique by definition.

The driver parses the ID from the internal object name. As far as I
understand the object model this ID is unique. But the ID might be
different if you look at the same guest through a esx:// or vpx://
connection, but it's unique per connection.

The name is a bit more tricky. For a single ESX server it's unique. I
thought for a vCenter it's unique per datacenter, because the vCenter
won't let you define a second guest with an existing name. I just
played a bit with it and it seems there are ways to define two domains
with the same name in a single cluster. This is definitely a problem
and I'm not sure how to fix that, other than using hacks like adding
the ID to the name.

In order to have a guaranteed unique domain name for a vpx://
connection the final name will probably have to be build like this

  //-

Quite ugly and unstable, because it'll change across a migration :(

The same name uniqueness problem exists for datastores, because their
names are unique per datacenter only.

Matthias

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

Re: [libvirt] [Qemu-devel] Re: [PATCH] Introduce a -libvirt-caps flag as a stop-gap

2010-07-27 Thread Chris Wright

* Anthony Liguori (anth...@codemonkey.ws) wrote:
> Here are the possible things we can do:
> 
> 1) merge -libvirt-caps as an intermediate solution, stop caring
> about -help changes, when full caps are introduced, stop updating
> -libvirt-caps
> 
> 2) don't merge -libvirt-caps, stop caring about -help changes, put
> everything on getting full caps merged by 0.14
> 
> 3) don't merge -libvirt-caps, care about making -help changes, use
> -help as the caps mechanism until full caps get merged

3.5) same as 3) + add test case to qemu to test that -help parser from
libvirt isn't busted.

> We can't do (3).  I'm going to revert the -help changes for 0.13 so
> that old versions of libvirt work but not for master.

I suspect that if the breakage is seen, it'd be easy to fix.  Adding new
help items won't be the problem, just the subtle changes to the existing
output.  Suck?  Yes.  Workable until full caps?  Think so.

thanks,
-chris

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

Re: [libvirt] [Qemu-devel] Re: [PATCH] Introduce a -libvirt-caps flag as a stop-gap

2010-07-27 Thread Anthony Liguori


On 07/27/2010 12:00 PM, Daniel P. Berrange wrote:

Yup.  You'll need to decide up front if you want to probe for a feature
when it's introduced and have something added to capabilities.

This is simple though.  A few weeks before 0.14 is released, go through
the change log, and anything that looks interesting, add a cap flag.
 

That doesn't work for features which already exist in QEMU which are
not yet supported in libvirt. eg consider QEMU 0.13 is released, and
then we want to add a new feature to libvirt a month later.


Right.  So sit down and look at the 0.13 changelog and if there's any 
features that you think you might want to support at some point in time, 
add a capability.



  We can't
simply add something extra to the capabilities because QEMU is already
released at this point. There is a large amount of stuff that falls
into this category.
   


It doesn't have to be perfect, it just has to be good enough.


  Adding a one-off special case for
the 0.13 release that we know will be obsolete in 0.14
   

IIF capabilities gets merged by 0.14.  I'd certainly like it to, but I'd
prefer to hedge my bets.

Here are the possible things we can do:

1) merge -libvirt-caps as an intermediate solution, stop caring about
-help changes, when full caps are introduced, stop updating -libvirt-caps

2) don't merge -libvirt-caps, stop caring about -help changes, put
everything on getting full caps merged by 0.14

3) don't merge -libvirt-caps, care about making -help changes, use -help
as the caps mechanism until full caps get merged

We can't do (3).  I'm going to revert the -help changes for 0.13 so that
old versions of libvirt work but not for master.

(2) makes me pretty uncomfortable because it implies either (a) delay
0.14 until full caps are ready (b) ship 0.14 such that libvirt is
totally broken.

(1) isn't ideal, I'll freely admit, but it's a workable intermediate
solution.
 

It offers significantly less information that the existing -help
data, so I don't think it is workable as a replacement. We'd get
into the bad situation where we could support a feature in 0.12
but not in 0.13, unless we went back to using -help output again.

If we're going for a short term hack, then how about a combination
of

http://www.mail-archive.com/qemu-de...@nongnu.org/msg34944.html
http://www.mail-archive.com/qemu-de...@nongnu.org/msg34960.html
   


Would have failed in exactly the same way that the current -help parsing 
fails.  The description of an argument in the help text is not a 
capabilities string.


Regards,

Anthony Liguori


so that we have the same level of information as '-help' but in
a more stable&  machine friendly format.

As we add further patches for capabilities, we'll migrate
away from the 'query-help' data and into the other capabilities
commands "query-netdevtypes" 'query-config' etc.

Daniel
   


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

Re: [libvirt] [Qemu-devel] Re: [PATCH] Introduce a -libvirt-caps flag as a stop-gap

2010-07-27 Thread Daniel P. Berrange

On Tue, Jul 27, 2010 at 11:38:04AM -0500, Anthony Liguori wrote:
> On 07/27/2010 11:09 AM, Daniel P. Berrange wrote:
> >On Tue, Jul 27, 2010 at 10:55:03AM -0500, Anthony Liguori wrote:
> >   
> >>Today libvirt parses -help output to attempt to enumerate capabilities.  
> >>This
> >>is very broken and has led to multiple failures.  Since libvirt is an 
> >>important
> >>management interface to QEMU, we need to do a better job giving them the 
> >>ability
> >>to detect what a QEMU executable supports.  Right now, we keep fixing up 
> >>help
> >>output to appease it's parsing code but this is undesirable.
> >>
> >>The Right Solution is to introduce a robust capabilities advertisement 
> >>that
> >>enumerates every feature we have.  As with most Right Solutions, we don't 
> >>have
> >>mergable code today and it's unclear that we'll get there by the next 
> >>release.
> >>
> >>This patch introduces an incremental solution of just spitting out the 
> >>handful
> >>of capabilities libvirt is probing for today.  This interface will need to
> >>remain forever but can stop being updated once we have a Right Solution.
> >> 
> >This isn't really workable because it only encodes the subset of things
> >that libvirt currently looks for. If someone comes along with a libvirt
> >patch for a new features that is already supported by QEMU, but isn't
> >in this simple output, we're stuck.
> 
> Yup.  You'll need to decide up front if you want to probe for a feature 
> when it's introduced and have something added to capabilities.
> 
> This is simple though.  A few weeks before 0.14 is released, go through 
> the change log, and anything that looks interesting, add a cap flag.

That doesn't work for features which already exist in QEMU which are
not yet supported in libvirt. eg consider QEMU 0.13 is released, and
then we want to add a new feature to libvirt a month later. We can't
simply add something extra to the capabilities because QEMU is already
released at this point. There is a large amount of stuff that falls
into this category.

> >  Adding a one-off special case for
> >the 0.13 release that we know will be obsolete in 0.14
> 
> IIF capabilities gets merged by 0.14.  I'd certainly like it to, but I'd 
> prefer to hedge my bets.
> 
> Here are the possible things we can do:
> 
> 1) merge -libvirt-caps as an intermediate solution, stop caring about 
> -help changes, when full caps are introduced, stop updating -libvirt-caps
> 
> 2) don't merge -libvirt-caps, stop caring about -help changes, put 
> everything on getting full caps merged by 0.14
> 
> 3) don't merge -libvirt-caps, care about making -help changes, use -help 
> as the caps mechanism until full caps get merged
> 
> We can't do (3).  I'm going to revert the -help changes for 0.13 so that 
> old versions of libvirt work but not for master.
> 
> (2) makes me pretty uncomfortable because it implies either (a) delay 
> 0.14 until full caps are ready (b) ship 0.14 such that libvirt is 
> totally broken.
> 
> (1) isn't ideal, I'll freely admit, but it's a workable intermediate 
> solution.

It offers significantly less information that the existing -help
data, so I don't think it is workable as a replacement. We'd get
into the bad situation where we could support a feature in 0.12
but not in 0.13, unless we went back to using -help output again.

If we're going for a short term hack, then how about a combination
of 

http://www.mail-archive.com/qemu-de...@nongnu.org/msg34944.html
http://www.mail-archive.com/qemu-de...@nongnu.org/msg34960.html

so that we have the same level of information as '-help' but in
a more stable & machine friendly format. 

As we add further patches for capabilities, we'll migrate 
away from the 'query-help' data and into the other capabilities
commands "query-netdevtypes" 'query-config' etc.

Daniel
-- 
|: Red Hat, Engineering, London-o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org-o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

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

Re: [libvirt] [Qemu-devel] Re: [PATCH] Introduce a -libvirt-caps flag as a stop-gap

2010-07-27 Thread Anthony Liguori


On 07/27/2010 11:09 AM, Daniel P. Berrange wrote:

On Tue, Jul 27, 2010 at 10:55:03AM -0500, Anthony Liguori wrote:
   

Today libvirt parses -help output to attempt to enumerate capabilities.  This
is very broken and has led to multiple failures.  Since libvirt is an important
management interface to QEMU, we need to do a better job giving them the ability
to detect what a QEMU executable supports.  Right now, we keep fixing up help
output to appease it's parsing code but this is undesirable.

The Right Solution is to introduce a robust capabilities advertisement that
enumerates every feature we have.  As with most Right Solutions, we don't have
mergable code today and it's unclear that we'll get there by the next release.

This patch introduces an incremental solution of just spitting out the handful
of capabilities libvirt is probing for today.  This interface will need to
remain forever but can stop being updated once we have a Right Solution.
 

This isn't really workable because it only encodes the subset of things
that libvirt currently looks for. If someone comes along with a libvirt
patch for a new features that is already supported by QEMU, but isn't
in this simple output, we're stuck.


Yup.  You'll need to decide up front if you want to probe for a feature 
when it's introduced and have something added to capabilities.


This is simple though.  A few weeks before 0.14 is released, go through 
the change log, and anything that looks interesting, add a cap flag.



  Adding a one-off special case for
the 0.13 release that we know will be obsolete in 0.14


IIF capabilities gets merged by 0.14.  I'd certainly like it to, but I'd 
prefer to hedge my bets.


Here are the possible things we can do:

1) merge -libvirt-caps as an intermediate solution, stop caring about 
-help changes, when full caps are introduced, stop updating -libvirt-caps


2) don't merge -libvirt-caps, stop caring about -help changes, put 
everything on getting full caps merged by 0.14


3) don't merge -libvirt-caps, care about making -help changes, use -help 
as the caps mechanism until full caps get merged


We can't do (3).  I'm going to revert the -help changes for 0.13 so that 
old versions of libvirt work but not for master.


(2) makes me pretty uncomfortable because it implies either (a) delay 
0.14 until full caps are ready (b) ship 0.14 such that libvirt is 
totally broken.


(1) isn't ideal, I'll freely admit, but it's a workable intermediate 
solution.


Regards,

Anthony Liguori


, and obviously
can't be used in qemu<  0.12 is not really a worthwhile use of time.
libvirt has to keep supporting help parsing indefinitely for<= 0.12
releases&  expects to support a new extensible&  flexible approach for
qemu>= 0.14. Adding a special case that both libvirt&  qemu have to
support indefinitely for 0.13 is not really very nice.

Daniel
   


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

Re: [libvirt] [PATCH] Introduce a -libvirt-caps flag as a stop-gap

2010-07-27 Thread Daniel P. Berrange

On Tue, Jul 27, 2010 at 10:55:03AM -0500, Anthony Liguori wrote:
> Today libvirt parses -help output to attempt to enumerate capabilities.  This
> is very broken and has led to multiple failures.  Since libvirt is an 
> important
> management interface to QEMU, we need to do a better job giving them the 
> ability
> to detect what a QEMU executable supports.  Right now, we keep fixing up help
> output to appease it's parsing code but this is undesirable.
> 
> The Right Solution is to introduce a robust capabilities advertisement that
> enumerates every feature we have.  As with most Right Solutions, we don't have
> mergable code today and it's unclear that we'll get there by the next release.
> 
> This patch introduces an incremental solution of just spitting out the handful
> of capabilities libvirt is probing for today.  This interface will need to
> remain forever but can stop being updated once we have a Right Solution.

This isn't really workable because it only encodes the subset of things
that libvirt currently looks for. If someone comes along with a libvirt
patch for a new features that is already supported by QEMU, but isn't
in this simple output, we're stuck. Adding a one-off special case for
the 0.13 release that we know will be obsolete in 0.14, and obviously
can't be used in qemu < 0.12 is not really a worthwhile use of time.
libvirt has to keep supporting help parsing indefinitely for <= 0.12
releases & expects to support a new extensible & flexible approach for
qemu >= 0.14. Adding a special case that both libvirt & qemu have to
support indefinitely for 0.13 is not really very nice.

Daniel
-- 
|: Red Hat, Engineering, London-o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org-o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

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

[libvirt] [PATCH] Introduce a -libvirt-caps flag as a stop-gap

2010-07-27 Thread Anthony Liguori

Today libvirt parses -help output to attempt to enumerate capabilities.  This
is very broken and has led to multiple failures.  Since libvirt is an important
management interface to QEMU, we need to do a better job giving them the ability
to detect what a QEMU executable supports.  Right now, we keep fixing up help
output to appease it's parsing code but this is undesirable.

The Right Solution is to introduce a robust capabilities advertisement that
enumerates every feature we have.  As with most Right Solutions, we don't have
mergable code today and it's unclear that we'll get there by the next release.

This patch introduces an incremental solution of just spitting out the handful
of capabilities libvirt is probing for today.  This interface will need to
remain forever but can stop being updated once we have a Right Solution.

Signed-off-by: Anthony Liguori 

diff --git a/qemu-options.hx b/qemu-options.hx
index 40cee70..a618914 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -2235,7 +2235,26 @@ Normally QEMU loads a configuration file from 
@var{sysconfdir}/qemu.conf and
 option will prevent QEMU from loading these configuration files at startup.
 ETEXI
 
+DEF("libvirt-caps", 0, QEMU_OPTION_libvirt_caps,
+"-libvirt-caps   output libvirt-specific capabilities\n",
+QEMU_ARCH_ALL)
+STEXI
+...@item -libvirt-caps
+...@findex -libvirt-caps
+Output a common separate list of capabilities that this version of QEMU
+supports and exit.  This interface specifically exists for libvirt's use as an
+intermediate solution until we support a full capabilities system.  One this
+capabilities system exist, this option's output should never change.
+
+The format out this command is:
+
+version: VERSION
+package: PACKAGE
+caps: CAP1[,CAP2...]
+ETEXI
+
 HXCOMM This is the last statement. Insert new options before this line!
 STEXI
 @end table
 ETEXI
+
diff --git a/vl.c b/vl.c
index ba6ee11..8fe354d 100644
--- a/vl.c
+++ b/vl.c
@@ -2616,6 +2616,14 @@ int main(int argc, char **argv, char **envp)
 fclose(fp);
 break;
 }
+case QEMU_OPTION_libvirt_caps:
+printf("version: " QEMU_VERSION "\n"
+   "package: " QEMU_PKGVERSION "\n"
+   "caps: name,enable-kvm,no-reboot,uuid,xen-domid,drive"
+   ",cache-v2,format,vga,serial,mem-path,chardev,balloon"
+   ",device,rtc,netdev,sdl,topology\n");
+exit(0);
+break;
 default:
 os_parse_cmd_args(popt->index, optarg);
 }
-- 
1.7.0.4

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

Re: [libvirt] [PATCH] libvirt-guests: Don't throw errors if libvirtd is not installed

2010-07-27 Thread Jiri Denemark

> > When only client parts of libvirt are installed (i.e., no libvirtd
> > daemon), libvirt-guests init script in its default configuration would
> > throw seriously looking errors during host shutdown:
> > 
> > Running guests on default URI: error: unable to connect to
> > '/var/run/libvirt/libvirt-sock', libvirtd may need to be started: No
> > such file or directory
> > error: failed to connect to the hypervisor
> > 
> > This patch changes the script to print rather harmless message in that
> > situation:
> > 
> > Running guests on default URI: libvirtd not installed; skipping this
> > URI.
> 
> ACK.

Thanks, pushed.

Jirka

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

Re: [libvirt] [PATCH] lxc: Fix return value handlings of vethInterfaceUpOrDown and moveInterfaceToNetNs

2010-07-27 Thread Ryota Ozaki

On Mon, Jul 26, 2010 at 11:37 PM, Laine Stump  wrote:
>  On 07/26/2010 08:31 AM, Ryota Ozaki wrote:
>>
>> On Mon, Jul 26, 2010 at 6:51 PM, Daniel P. Berrange
>>  wrote:
>>>
>>> On Sun, Jul 25, 2010 at 02:25:05AM +0900, Ryota Ozaki wrote:

 On Sat, Jul 24, 2010 at 11:44 PM, Ryota Ozaki
  wrote:
>
> Hi Laine,
>
> On Sat, Jul 24, 2010 at 2:58 AM, Laine Stump  wrote:
>>
>>  On 07/23/2010 01:25 PM, Ryota Ozaki wrote:
>>>
>>> Both may return a positive value when they fail. We should check
>>> if the value is not zero instead of checking if it's negative.
>>
>> I notice that  lxcSetupInterfaces has a comment saying that it returns
>> -1 on
>> failure, but it actually just passes on what is returned by
>> vethInterfaceUpOrDown.
>
> Oh, I didn't know that.
>
> Additionally, I found that other functions, e.g., setMacAddr, are also
> handled
> with the wrong way. And also handling return values with
> virReportSystemError
> is also wrong because it expects an errno, not an exit code. We have to
> fix
> all of them ;-<
>
>> Would you be willing to consider instead just changing
>> vethInterfaceUpOrDown
>> and moveInterfaceToNetNs to return -1 in all error cases (and checking
>> the
>> return for<  0), rather than grabbing the exit code of the exec'ed
>> command?
>> None of the callers do anything with that extra information anyway,
>> and it
>> would help to make the return values more consistent (which makes it
>> easier
>> to catch bugs like this, or eliminates them altogether ;-)
>
> Yeah, I'm also a bit annoying with the return values. Hmm, but we now
> show error
> messages with the return values outside the functions. Without that, we
> have to
> show the error message in the functions or some other place, otherwise
> we lose
> useful information of errors. It seems not good idea.
>
> One option is to let virRun show an error message by passing NULL to
> the second
> argument (status) of it, like brSetEnableSTP in util/bridge.c, and
> always return -1
> on a failure. It'd satisfy what you suggest.
>
> Honestly said, I cannot decide. Anyone has any suggestions on that?
>>>
>>> You could just change
>>>
>>>   return cmdResult
>>>
>>> to
>>>
>>>   return -cmdResult;
>>>
>>> That would still let you give the error code, while also keeping the
>>> value
>>> <  0
>>
>> It looks better than mine ;-) I'll rewrite my patch in such a way.
>>
>> Laine, is it ok for you too?
>>
>
> Doing that is fine when all possible failures in the function have an
> associated errno. In the case of virRun'ing an external program that could
> return a non-zero exit code, this is unfortunately not the case, so those
> functions that call virRun will need to report the error themselves and
> return -1.

For veth.c all functions match the latter case while bridge.c has both.
If we don't take care about the consistency between veth.c and bridge.c,
we can focus on how to treat the latter case. (Ideally keeping the consistency
is better, but it seems difficult...)

>
> When non-0 exits from the called program are all failures, the simplest way
> to do it is, as you say, to just not pass a pointer to a resultcode to
> virRun (as long as the error message reported by virRun is useful enough -

Yes.

> remember that it gives the name of the program being run, and "virRun", but
> not the name of the calling function).

Agreed. That'll lose useful information for debugging. One option is
to re-report
an error in the calling function. It will lead reporting two messages,
but it should
be more useful than less reports.

One concern aobut virRun's error reporting is that it shows standard
errors through
DEBUG so by default it shows nothing while they are important for ifconfig
and ip commands because their error messages may be according to errno.

>
> setMacAddr gives another example of a failure mode that breaks the "return
> -errno" paradigm - it checks for one of the arguments being NULL, and fails
> in that case. If it's important to maintain "-errno on failure" in one of
> those cases, possibly examining the code will show that the arg in question
> is never NULL, in which case you can mark it in its prototype with
> ATTRIBUTE_NONNULL and just eliminate that failure from the code.

That seems good idea. One exception is virAsprintf in moveInterfaceToNetNs,
although we can simply use virReportOOMError() for it and return -ENOMEM.

>
> It seems that in general, the -errno convention works better at lower levels
> where all the failures are related to some system call failing, but at some
> point higher in the call chain the possibility of failure due to config,
> etc, comes in, there is no valid errno to describe a problem, and then you
> need to start reporting the errors and returning -1.

Actually I had an experience that 'ip' c

[libvirt] Virt-install Error and kvm‏

2010-07-27 Thread cris rock


Hi guys, I hope you can help me on this issue with kvm/libvirt:



using this command to install a kvm virtual machine:



virt-install --connect qemu:///system \

--name p3k0401 \

--ram 2048 \

--file //dev/VolGroup01/p3k0401logvol \

--accelerate \

-s 10 \

--nographics \

--hvm \

--location='http://10.1.4.80'



I get:



Starting install...

Retrieving file vmlinuz... | 1.8 MB 00:00

Retrieving file initrd.img... | 7.1 MB 00:00

ERROR internal error Domain p3k0401 didn't show up



Domain installation may not have been

successful. If it was, you can restart your domain

by running 'virsh start p3k0401'; otherwise, please

restart your installation.

ERROR internal error Domain p3k0401 didn't show up

Traceback (most recent call last):

File "/usr/sbin/virt-install", line 889, in ?

main()

File "/usr/sbin/virt-install", line 751, in main

start_time, guest.start_install)

File "/usr/sbin/virt-install", line 813, in do_install

dom = install_func(conscb, progresscb, wait=(not wait))

File "/usr/lib/python2.4/site-packages/virtinst/Guest.py", line 541, in

start_install

return self._do_install(consolecb, meter, removeOld, wait)

File "/usr/lib/python2.4/site-packages/virtinst/Guest.py", line 633, in

_do_install

self.domain = self.conn.createLinux(install_xml, 0)

File "/usr/lib64/python2.4/site-packages/libvirt.py", line 974, in

createLinux

if ret is None:raise libvirtError('virDomainCreateLinux() failed',

conn=self)

libvirtError: internal error Domain p3k0401 didn't show up





On the /var/log/libvirt/qemu/p3k0401.log:



LC_ALL=C PATH=/sbin:/usr/sbin:/bin:/usr/bin HOME=/

/usr/bin/qemu-system-x86_64 -S -M rhel5.4.0 -m 1024 -smp 1 -name p3k0401

-uuid 7658c102-0738-724c-40eb-e1c58b2c2369 -domid 3 -nographic -monitor

pty -pidfile /var/run/libvirt/qemu//p3k0401.pid -no-reboot -boot c

-kernel /var/lib/libvirt/boot/virtinst-vmlinuz.O_SOVo -initrd

/var/lib/libvirt/boot/virtinst-initrd.img.0ba0Fp -append

method=http://10.1.4.80  -drive

file=//dev/VolGroup01/p3k0401logvol,if=ide,index=0,cache=none -net

nic,macaddr=54:52:00:15:c4:50,vlan=0 -net

tap,fd=16,script=,vlan=0,ifname=vnet0 -serial pty -parallel none -usb

Supported machines are:

pc Standard PC (alias of pc-0.12)

pc-0.12 Standard PC (default)

pc-0.11 Standard PC, qemu 0.11

pc-0.10 Standard PC, qemu 0.10

isapc ISA-only PC

xenpv Xen Para-virtualized PC





And my packages installed:



# rpm -qa | grep qemu

qemu-0.12.4-1.el5.rf



# rpm -qa | grep kvm

etherboot-zroms-kvm-5.4.4-13.el5.centos

kmod-kvm-83-164.el5_5.12

kvm-83-164.el5_5.12



# rpm -qa | grep libvirt

libvirt-0.6.3-33.el5_5.1

libvirt-0.6.3-33.el5_5.1

libvirt-python-0.6.3-33.el5_5.1



# uname -a

Linux gs1p304 2.6.18-164.el5 #1 SMP Thu Sep 3 03:28:30 EDT 2009 x86_64

x86_64 x86_64 GNU/Linux



Please any pointer is appreciated...



thanks!



cris
  
_
Hotmail: Free, trusted and rich email service.
https://signup.live.com/signup.aspx?id=60969--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] VMware Workstation/Player support

2010-07-27 Thread Daniel Veillard

On Tue, Jul 27, 2010 at 03:20:42PM +0200, Jean-Baptiste Rouault wrote:
> Hi all,
> 
> I'm working on the hynesim project (http://www.hynesim.org
> http://blog.hynesim.org).
> We are going to add VMware Workstation support to hynesim,
> so we would like to contribute to the development of a libvirt driver.
> 
> There probably are multiple ways of doing this, one of them could
> be to use the VIX C API provided by VMware :
> http://www.vmware.com/support/developer/vix-api/
> However, the VIX license seems to be quite restrictive :
> http://www.vmware.com/download/eula/vixapi_eula.html
> I'm not a license expert so I don't know if this license forbids
> using the API in software like libvirt.

  We had a look at the VIX Licence and it wasn't pretty, this EULA
seems to directly try to prevent reuse for anything except toying
with it.

  Another big problem is that it's not available for distribution
not packaged, it's a download from VMWare, i.e. it won't be present
in any build installation of distribution I think. As a result the
dependancy will make this impossible to support in default builds,
the only way being to download the vix library, and then rebuild
libvirt locally. Very painful !

> Another possibility could be to run VMware command line tools
> from libvirt to control guests.

  That sounds quite a better option, first we avoid the licencing
tie in, second we can have the driver detect at runtime if the command
line tools are available, and then activate or not the driver. This
allows to provide the compiled support in all libvirt builds, even
if only a fraction of the users may actually use VMware Workstation.

  So really it sounds like making the driver call directly the
command line tools is the right approach.
  Code wise the driver should be installed in a directory separated
from src/esx , and some tweaking might be needed to 'export' the
ESX config parser and make it available from there, but that should
not be too hard really.

Daniel

-- 
Daniel Veillard  | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
dan...@veillard.com  | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library  http://libvirt.org/

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

[libvirt] VMware Workstation/Player support

2010-07-27 Thread Jean-Baptiste Rouault

Hi all,

I'm working on the hynesim project (http://www.hynesim.org
http://blog.hynesim.org).
We are going to add VMware Workstation support to hynesim,
so we would like to contribute to the development of a libvirt driver.

There probably are multiple ways of doing this, one of them could
be to use the VIX C API provided by VMware :
http://www.vmware.com/support/developer/vix-api/
However, the VIX license seems to be quite restrictive :
http://www.vmware.com/download/eula/vixapi_eula.html
I'm not a license expert so I don't know if this license forbids
using the API in software like libvirt.

Another possibility could be to run VMware command line tools
from libvirt to control guests.

As Daniel P. Berrange stated on IRC yesterday, the vmx <-> XML
conversion code can be reused from the ESX driver.

I'd like to have your opinion about the "best" to implement this
VMware Workstation driver.

Regards,

Jean-Baptiste Rouault

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

Re: [libvirt] [PATCH] libvirt-guests: Don't throw errors if libvirtd is not installed

2010-07-27 Thread Eric Blake

On 07/27/2010 07:10 AM, Jiri Denemark wrote:
> When only client parts of libvirt are installed (i.e., no libvirtd
> daemon), libvirt-guests init script in its default configuration would
> throw seriously looking errors during host shutdown:
> 
> Running guests on default URI: error: unable to connect to
> '/var/run/libvirt/libvirt-sock', libvirtd may need to be started: No
> such file or directory
> error: failed to connect to the hypervisor
> 
> This patch changes the script to print rather harmless message in that
> situation:
> 
> Running guests on default URI: libvirtd not installed; skipping this
> URI.

ACK.

-- 
Eric Blake   ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org



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

[libvirt] [PATCH] libvirt-guests: Don't throw errors if libvirtd is not installed

2010-07-27 Thread Jiri Denemark

When only client parts of libvirt are installed (i.e., no libvirtd
daemon), libvirt-guests init script in its default configuration would
throw seriously looking errors during host shutdown:

Running guests on default URI: error: unable to connect to
'/var/run/libvirt/libvirt-sock', libvirtd may need to be started: No
such file or directory
error: failed to connect to the hypervisor

This patch changes the script to print rather harmless message in that
situation:

Running guests on default URI: libvirtd not installed; skipping this
URI.
---
 daemon/libvirt-guests.init.in |7 +++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/daemon/libvirt-guests.init.in b/daemon/libvirt-guests.init.in
index f99c070..d2ec96a 100644
--- a/daemon/libvirt-guests.init.in
+++ b/daemon/libvirt-guests.init.in
@@ -25,6 +25,7 @@
 
 sysconfd...@sysconfdir@
 localstated...@localstatedir@
+libvir...@sbindir@/libvirtd
 
 # Source function library.
 . "$sysconfdir"/rc.d/init.d/functions
@@ -232,6 +233,12 @@ stop() {
 : >"$LISTFILE"
 for uri in $URIS; do
 echo -n $"Running guests on $uri URI: "
+
+if [ "x$uri" = xdefault ] && [ ! -x "$libvirtd" ]; then
+echo $"libvirtd not installed; skipping this URI."
+continue
+fi
+
 list=$(list_guests $uri)
 if [ $? -eq 0 ]; then
 empty=true
-- 
1.7.2

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

Re: [libvirt] [PATCH] lxc: Fix return value handlings of vethInterfaceUpOrDown and moveInterfaceToNetNs

2010-07-27 Thread Ryota Ozaki

Hi Laine,


Hmm...I was eager to a conclusion. We need some more discussion to
a better way.

Nonetheless, I hope this fix and another which I found later to be
included in the next release that is expected soon. Is it OK for you,
Laine? Of course, I'll continue this discussion until we have a consensus.

  ozaki-r

On Mon, Jul 26, 2010 at 11:37 PM, Laine Stump  wrote:
>  On 07/26/2010 08:31 AM, Ryota Ozaki wrote:
>>
>> On Mon, Jul 26, 2010 at 6:51 PM, Daniel P. Berrange
>>  wrote:
>>>
>>> On Sun, Jul 25, 2010 at 02:25:05AM +0900, Ryota Ozaki wrote:

 On Sat, Jul 24, 2010 at 11:44 PM, Ryota Ozaki
  wrote:
>
> Hi Laine,
>
> On Sat, Jul 24, 2010 at 2:58 AM, Laine Stump  wrote:
>>
>>  On 07/23/2010 01:25 PM, Ryota Ozaki wrote:
>>>
>>> Both may return a positive value when they fail. We should check
>>> if the value is not zero instead of checking if it's negative.
>>
>> I notice that  lxcSetupInterfaces has a comment saying that it returns
>> -1 on
>> failure, but it actually just passes on what is returned by
>> vethInterfaceUpOrDown.
>
> Oh, I didn't know that.
>
> Additionally, I found that other functions, e.g., setMacAddr, are also
> handled
> with the wrong way. And also handling return values with
> virReportSystemError
> is also wrong because it expects an errno, not an exit code. We have to
> fix
> all of them ;-<
>
>> Would you be willing to consider instead just changing
>> vethInterfaceUpOrDown
>> and moveInterfaceToNetNs to return -1 in all error cases (and checking
>> the
>> return for<  0), rather than grabbing the exit code of the exec'ed
>> command?
>> None of the callers do anything with that extra information anyway,
>> and it
>> would help to make the return values more consistent (which makes it
>> easier
>> to catch bugs like this, or eliminates them altogether ;-)
>
> Yeah, I'm also a bit annoying with the return values. Hmm, but we now
> show error
> messages with the return values outside the functions. Without that, we
> have to
> show the error message in the functions or some other place, otherwise
> we lose
> useful information of errors. It seems not good idea.
>
> One option is to let virRun show an error message by passing NULL to
> the second
> argument (status) of it, like brSetEnableSTP in util/bridge.c, and
> always return -1
> on a failure. It'd satisfy what you suggest.
>
> Honestly said, I cannot decide. Anyone has any suggestions on that?
>>>
>>> You could just change
>>>
>>>   return cmdResult
>>>
>>> to
>>>
>>>   return -cmdResult;
>>>
>>> That would still let you give the error code, while also keeping the
>>> value
>>> <  0
>>
>> It looks better than mine ;-) I'll rewrite my patch in such a way.
>>
>> Laine, is it ok for you too?
>>
>
> Doing that is fine when all possible failures in the function have an
> associated errno. In the case of virRun'ing an external program that could
> return a non-zero exit code, this is unfortunately not the case, so those
> functions that call virRun will need to report the error themselves and
> return -1.
>
> When non-0 exits from the called program are all failures, the simplest way
> to do it is, as you say, to just not pass a pointer to a resultcode to
> virRun (as long as the error message reported by virRun is useful enough -
> remember that it gives the name of the program being run, and "virRun", but
> not the name of the calling function).
>
> setMacAddr gives another example of a failure mode that breaks the "return
> -errno" paradigm - it checks for one of the arguments being NULL, and fails
> in that case. If it's important to maintain "-errno on failure" in one of
> those cases, possibly examining the code will show that the arg in question
> is never NULL, in which case you can mark it in its prototype with
> ATTRIBUTE_NONNULL and just eliminate that failure from the code.
>
> It seems that in general, the -errno convention works better at lower levels
> where all the failures are related to some system call failing, but at some
> point higher in the call chain the possibility of failure due to config,
> etc, comes in, there is no valid errno to describe a problem, and then you
> need to start reporting the errors and returning -1.
>
> --
> 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] qemu: Allow setting boot menu on/off

2010-07-27 Thread Daniel Veillard

On Tue, Jul 27, 2010 at 08:48:07AM -0400, Cole Robinson wrote:
> On 07/27/2010 06:13 AM, Daniel P. Berrange wrote:
> > On Mon, Jul 26, 2010 at 04:31:23PM -0400, Cole Robinson wrote:
> >> Add a new element to the  block:
> >>
> >>   
> >>
> >> Which maps to -boot,menu=on|off on the QEMU command line.
> >>
> >> I decided to use an explicit 'enable' attribute rather than just make the
> >> bootmenu element boolean. This allows us to treat lack of a bootmenu 
> >> element
> >> as 'use hypervisor default'.
> >>
> >> Signed-off-by: Cole Robinson 
> > 
> > I'm wondering what we should do if we need a further option
> > to turn on/off the PXE boot menus that SEABIOS now adds to
> > QEMU for each NIC. I guess that might be a separate 
> >  element within the  device so probably
> > wouldn't impact this modelling
> > 
> 
> Yeah, I think we eventually need some sort of  element at the
> device level anyways, to support booting off hdb instead of hda for
> example. But yeah, I don't think it should affect this patch.

  Agreed, ACK,

Daniel

-- 
Daniel Veillard  | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
dan...@veillard.com  | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library  http://libvirt.org/

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

Re: [libvirt] [PATCH] qemu: Allow setting boot menu on/off

2010-07-27 Thread Cole Robinson

On 07/27/2010 06:13 AM, Daniel P. Berrange wrote:
> On Mon, Jul 26, 2010 at 04:31:23PM -0400, Cole Robinson wrote:
>> Add a new element to the  block:
>>
>>   
>>
>> Which maps to -boot,menu=on|off on the QEMU command line.
>>
>> I decided to use an explicit 'enable' attribute rather than just make the
>> bootmenu element boolean. This allows us to treat lack of a bootmenu element
>> as 'use hypervisor default'.
>>
>> Signed-off-by: Cole Robinson 
> 
> I'm wondering what we should do if we need a further option
> to turn on/off the PXE boot menus that SEABIOS now adds to
> QEMU for each NIC. I guess that might be a separate 
>  element within the  device so probably
> wouldn't impact this modelling
> 

Yeah, I think we eventually need some sort of  element at the
device level anyways, to support booting off hdb instead of hda for
example. But yeah, I don't think it should affect this patch.

- Cole

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

Re: [libvirt] [PATCH 4/5] domain conf: Support multiple devices

2010-07-27 Thread Cole Robinson

On 07/27/2010 06:07 AM, Daniel P. Berrange wrote:
> On Mon, Jul 26, 2010 at 03:11:36PM -0400, Cole Robinson wrote:
>> On 07/19/2010 11:42 AM, Daniel P. Berrange wrote:
>>> On Wed, Jul 14, 2010 at 03:44:55PM -0400, Cole Robinson wrote:
 Change console handling to a proper device list, as done for other
 character devices. Even though certain drivers can actually handle multiple
 consoles, for now just maintain existing behavior where possible.

 Signed-off-by: Cole Robinson 
>>>
>>> [snip]
>>>
 -chr->target.port = 0;
 -/*
 - * For HVM console actually created a serial device
 - * while for non-HVM it was a parvirt console
 - */
 -if (STREQ(def->os.type, "hvm")) {
 -if (def->nserials != 0) {
 -virDomainChrDefFree(chr);
 -} else {
 -if (VIR_ALLOC_N(def->serials, 1) < 0) {
 +chr->target.port = i;
 +
 +/* Back compat handling for the first console device */
 +if (i == 0) {
 +/*
 +* For HVM console actually created a serial device
 +* while for non-HVM it was a parvirt console
 +*/
 +if (STREQ(def->os.type, "hvm")) {
 +if (def->nserials != 0) {
  virDomainChrDefFree(chr);
 -goto no_memory;
 +} else {
 +if (VIR_ALLOC_N(def->serials, 1) < 0) {
 +virDomainChrDefFree(chr);
 +goto no_memory;
 +}
 +def->nserials = 1;
 +def->serials[0] = chr;
 +chr->deviceType = VIR_DOMAIN_CHR_DEVICE_TYPE_SERIAL;
  }
 -def->nserials = 1;
 -def->serials[0] = chr;
 -chr->deviceType = VIR_DOMAIN_CHR_DEVICE_TYPE_SERIAL;
 +} else {
 +def->consoles[def->nconsoles++] = chr;
  }
  } else {
 -def->console = chr;
 +def->consoles[def->nconsoles++] = chr;
  }
  }
>>>
>>> This is where we get into a bit of a mess with back compatability,
>>> when combined with the later DefFormat code.
>>>
>>> The original requirement is that a  element generates
>>> a  element for HVM guests. In the original code we throw
>>> away the virDomainChrDef for the console, since we re-generate
>>> it at format time if nconsoles==0.  This hack can't work anymore
>>> with multiple consoles. Since if we have 2 consoles in the XML
>>> and throw away console 0, we have nconsoles==1 during DefFormat
>>> and thus won't re-generate the original console 0. To further
>>> complicate life, we don't want todo any of this  compat
>>> code this at all if console 0 is a virtio console.
>>>
>>>
 @@ -5496,9 +5512,10 @@ virDomainChrDefFormat(virBufferPtr buf,
  return -1;
  }
  
 -/* Compat with legacy   syntax */
  virBufferVSprintf(buf, "<%s type='%s'",
elementName, type);
 +
 +/* Compat with legacy   syntax */
  if (def->deviceType == VIR_DOMAIN_CHR_DEVICE_TYPE_CONSOLE &&
  def->type == VIR_DOMAIN_CHR_TYPE_PTY &&
  !(flags & VIR_DOMAIN_XML_INACTIVE) &&
>>>
>>> Since we're allowing multiple  now, we should restrict this
>>> hack to just the first one.
>>>
 @@ -6213,9 +6230,10 @@ char *virDomainDefFormat(virDomainDefPtr def,
  goto cleanup;
  
  /* If there's a PV console that's preferred.. */
 -if (def->console) {
 -if (virDomainChrDefFormat(&buf, def->console, flags) < 0)
 -goto cleanup;
 +if (def->nconsoles) {
 +for (n = 0 ; n < def->nconsoles ; n++)
 +if (virDomainChrDefFormat(&buf, def->consoles[n], flags) < 0)
 +goto cleanup;
  } else if (def->nserials != 0) {
  /* ..else for legacy compat duplicate the first serial device as a
   * console */
>>>
>>> This logic can't work anymore.
>>>
>>>
>>> What I think we need todo is to remove the hacks in both the Parse and
>>> Format methods.  Then add one single hack for the parse method which
>>> simply adds a matching  device if nserial==0 and the console
>>> device type is serial. 
>>>
>>
>> I poked at this for a while, and it's a big pain. Adding a single hack
>> in the XML parse step isn't enough, because drivers like xen and esx
>> build up a domain def manually in certain cases, so wouldn't gain the
>> benefit of a hack in the parse function.
> 
> Can't we just manually add an equivalent hack in those drivers where
> necessary ? We used to that in Xen in the past at least.
> 

Yeah that would work too, I didn't try it though.

- Col

Re: [libvirt] [PATCH] Invert logic for checking for QEMU disk cache options

2010-07-27 Thread Cole Robinson

On 07/27/2010 06:23 AM, Daniel P. Berrange wrote:
> QEMU has had two different syntax for disk cache options
> 
>  Old: on|off
>  New: writeback|writethrough|none
> 
> QEMU recently added another 'unsafe' option which broke the
> libvirt check. We can avoid this & future breakage, if we
> do a negative check for the old syntax, instead of a positive
> check for the new syntax
> 
> * src/qemu/qemu_conf.c: Invert cache option check
> ---
>  src/qemu/qemu_conf.c |3 ++-
>  1 files changed, 2 insertions(+), 1 deletions(-)
> 
> diff --git a/src/qemu/qemu_conf.c b/src/qemu/qemu_conf.c
> index 0dbab48..db60ca3 100644
> --- a/src/qemu/qemu_conf.c
> +++ b/src/qemu/qemu_conf.c
> @@ -1170,7 +1170,8 @@ static unsigned long long qemudComputeCmdFlags(const 
> char *help,
>  flags |= QEMUD_CMD_FLAG_DOMID;
>  if (strstr(help, "-drive")) {
>  flags |= QEMUD_CMD_FLAG_DRIVE;
> -if (strstr(help, "cache=writethrough|writeback|none"))
> +if (strstr(help, "cache=") &&
> +!strstr(help, "cache=on|off"))
>  flags |= QEMUD_CMD_FLAG_DRIVE_CACHE_V2;
>  if (strstr(help, "format="))
>  flags |= QEMUD_CMD_FLAG_DRIVE_FORMAT;

ACK

- Cole

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

Re: [libvirt] [PATCH] Force FLR on for buggy SR-IOV devices.

2010-07-27 Thread Chris Lalancette

On 07/26/10 - 01:45:29PM, Eric Blake wrote:
> On 07/26/2010 12:51 PM, Chris Lalancette wrote:
> > Some buggy PCI devices actually support FLR, but
> > forget to advertise that fact in their PCI config space.
> > However, Virtual Functions on SR-IOV devices are
> > *required* to support FLR by the spec, so force has_flr
> > on if this is a virtual function.
> > 
> > Signed-off-by: Chris Lalancette 
> > ---
> >  src/util/pci.c |   48 
> >  1 files changed, 44 insertions(+), 4 deletions(-)
> >  
> > +/* there are some buggy devices that do support FLR, but forget to
> > + * advertise that fact in their capabilities.  However, FLR is 
> > *required*
> > + * to be present for virtual functions (VFs), so if we see that this
> > + * device is a VF, we just assume FLR works
> > + */
> > +
> > +if (virAsprintf(&path, PCI_SYSFS "devices/%s/physfn", dev->name) < 0) {
> > +virReportOOMError();
> > +return -1;
> 
> ACK - this fixed my concerns from v1.

Thanks, I've pushed this.

--
Chris Lalancette

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

Re: [libvirt] [PATCH 1/5] virt-aa-helper: Ignore open errors again

2010-07-27 Thread Matthias Bolte

2010/7/27 Daniel P. Berrange :
> On Tue, Jul 27, 2010 at 11:46:34AM +0200, Matthias Bolte wrote:
>> 2010/7/26 Daniel P. Berrange :
>> > On Sat, Jul 24, 2010 at 12:28:11AM +0200, Jamie Strandboge wrote:
>> >> On Fri, 2010-07-23 at 19:24 +0200, Matthias Bolte wrote:
>> >> > virt-aa-helper used to ignore errors when opening files.
>> >> > Commit a8853344994a7c6aaca882a5e949ab5536821ab5 refactored
>> >> > the related code and changed this behavior. virt-aa-helper
>> >> > didn't ignore open errors anymore and virt-aa-helper-test
>> >> > fails.
>> >> >
>> >> > Make sure that virt-aa-helper ignores open errors again.
>> >> > ---
>> >> >  src/security/virt-aa-helper.c |    2 +-
>> >> >  1 files changed, 1 insertions(+), 1 deletions(-)
>> >> >
>> >> > diff --git a/src/security/virt-aa-helper.c 
>> >> > b/src/security/virt-aa-helper.c
>> >> > index 521545d..16b1920 100644
>> >> > --- a/src/security/virt-aa-helper.c
>> >> > +++ b/src/security/virt-aa-helper.c
>> >> > @@ -846,7 +846,7 @@ get_files(vahControl * ctl)
>> >> >      for (i = 0; i < ctl->def->ndisks; i++) {
>> >> >          int ret = virDomainDiskDefForeachPath(ctl->def->disks[i],
>> >> >                                                
>> >> > ctl->allowDiskFormatProbing,
>> >> > -                                              false,
>> >> > +                                              true,
>> >> >                                                add_file_path,
>> >> >                                                &buf);
>> >> >          if (ret != 0)
>> >>
>> >> I'm not 100% sure on this one. I have been developing patches to adjust
>> >> for the new behavior on older releases and I did some shuffling to get
>> >> this to work with 'false'. I'm not ready to submit at this time, and
>> >> won't be able to get to it until the week after next. If this blocks
>> >> Matthias' work, then feel free to commit and I'll post with a different
>> >> patch if needed. Otherwise, we can wait.
>> >
>> > What is the scenario in which 'false' breaks things ? We use 'false' for
>> > the selinux driver already. The problem with 'true' is that it means the
>> > user will never see potentially important errors.
>> >
>> > Regards,
>> > Daniel
>>
>> Maybe it's a problem that's triggered by the test only.
>>
>> Passing 'false' makes virt-aa-helper-test fail for tests that involve
>> non-existing files:
>>
>> $ ./virt-aa-helper-test
>> FAIL: exited with '1'
>>   create (non-existent disk):  '--dryrun -c -u
>> libvirt-----0123456789ab':
>> FAIL: exited with '1'
>>   replace (non-existent disk):  '--dryrun -r -u
>> libvirt-----0123456789ab':
>>
>> Here's the command that virt-aa-helper-test executes for the first failing 
>> test:
>>
>> $ LD_LIBRARY_PATH="../src/.libs/" ../src/virt-aa-helper --dryrun -c -u
>> libvirt-----0123456789ab <
>> /tmp/tmp.IFQ5dqTvp6/test.xml
>> virt-aa-helper: warning: path does not exist, skipping file type checks
>> virt-aa-helper: error: invalid VM definition
>
> Hmm, this does look like a test script bug. It should at least touch
> the files so they exist before running. If a real deployment you would
> actually want these kind of error messages about non-existant files.
>

I don't think that it's a bug in the test script in the way that it
should touch the files. The test are named "create (non-existent
disk)" and "replace (non-existent disk)". I think the are meant to
work with non-existent files.

As I think of it, I'm not sure whether or not this two tests cases
should be there at all.

Is there a real use case with non-existent files that this two test
cover? If not then we could back to 'true' and remove this two test
cases.

Matthias

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

Re: [libvirt] [PATCH 1/5] virt-aa-helper: Ignore open errors again

2010-07-27 Thread Daniel P. Berrange

On Tue, Jul 27, 2010 at 12:49:45PM +0200, Matthias Bolte wrote:
> 2010/7/27 Daniel P. Berrange :
> > On Tue, Jul 27, 2010 at 11:46:34AM +0200, Matthias Bolte wrote:
> >> 2010/7/26 Daniel P. Berrange :
> >> > On Sat, Jul 24, 2010 at 12:28:11AM +0200, Jamie Strandboge wrote:
> >> >> On Fri, 2010-07-23 at 19:24 +0200, Matthias Bolte wrote:
> >> >> > virt-aa-helper used to ignore errors when opening files.
> >> >> > Commit a8853344994a7c6aaca882a5e949ab5536821ab5 refactored
> >> >> > the related code and changed this behavior. virt-aa-helper
> >> >> > didn't ignore open errors anymore and virt-aa-helper-test
> >> >> > fails.
> >> >> >
> >> >> > Make sure that virt-aa-helper ignores open errors again.
> >> >> > ---
> >> >> >  src/security/virt-aa-helper.c |    2 +-
> >> >> >  1 files changed, 1 insertions(+), 1 deletions(-)
> >> >> >
> >> >> > diff --git a/src/security/virt-aa-helper.c 
> >> >> > b/src/security/virt-aa-helper.c
> >> >> > index 521545d..16b1920 100644
> >> >> > --- a/src/security/virt-aa-helper.c
> >> >> > +++ b/src/security/virt-aa-helper.c
> >> >> > @@ -846,7 +846,7 @@ get_files(vahControl * ctl)
> >> >> >      for (i = 0; i < ctl->def->ndisks; i++) {
> >> >> >          int ret = virDomainDiskDefForeachPath(ctl->def->disks[i],
> >> >> >                                                
> >> >> > ctl->allowDiskFormatProbing,
> >> >> > -                                              false,
> >> >> > +                                              true,
> >> >> >                                                add_file_path,
> >> >> >                                                &buf);
> >> >> >          if (ret != 0)
> >> >>
> >> >> I'm not 100% sure on this one. I have been developing patches to adjust
> >> >> for the new behavior on older releases and I did some shuffling to get
> >> >> this to work with 'false'. I'm not ready to submit at this time, and
> >> >> won't be able to get to it until the week after next. If this blocks
> >> >> Matthias' work, then feel free to commit and I'll post with a different
> >> >> patch if needed. Otherwise, we can wait.
> >> >
> >> > What is the scenario in which 'false' breaks things ? We use 'false' for
> >> > the selinux driver already. The problem with 'true' is that it means the
> >> > user will never see potentially important errors.
> >> >
> >> > Regards,
> >> > Daniel
> >>
> >> Maybe it's a problem that's triggered by the test only.
> >>
> >> Passing 'false' makes virt-aa-helper-test fail for tests that involve
> >> non-existing files:
> >>
> >> $ ./virt-aa-helper-test
> >> FAIL: exited with '1'
> >>   create (non-existent disk):  '--dryrun -c -u
> >> libvirt-----0123456789ab':
> >> FAIL: exited with '1'
> >>   replace (non-existent disk):  '--dryrun -r -u
> >> libvirt-----0123456789ab':
> >>
> >> Here's the command that virt-aa-helper-test executes for the first failing 
> >> test:
> >>
> >> $ LD_LIBRARY_PATH="../src/.libs/" ../src/virt-aa-helper --dryrun -c -u
> >> libvirt-----0123456789ab <
> >> /tmp/tmp.IFQ5dqTvp6/test.xml
> >> virt-aa-helper: warning: path does not exist, skipping file type checks
> >> virt-aa-helper: error: invalid VM definition
> >
> > Hmm, this does look like a test script bug. It should at least touch
> > the files so they exist before running. If a real deployment you would
> > actually want these kind of error messages about non-existant files.
> >
> 
> I don't think that it's a bug in the test script in the way that it
> should touch the files. The test are named "create (non-existent
> disk)" and "replace (non-existent disk)". I think the are meant to
> work with non-existent files.
> 
> As I think of it, I'm not sure whether or not this two tests cases
> should be there at all.
>
> Is there a real use case with non-existent files that this two test
> cover? If not then we could back to 'true' and remove this two test
> cases.

Perhaps the tests should be changed to verify that it failed, since I
think that is the desired behaviour with non-existant files

Daniel
-- 
|: Red Hat, Engineering, London-o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org-o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

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

[libvirt] [PATCH] Invert logic for checking for QEMU disk cache options

2010-07-27 Thread Daniel P. Berrange

QEMU has had two different syntax for disk cache options

 Old: on|off
 New: writeback|writethrough|none

QEMU recently added another 'unsafe' option which broke the
libvirt check. We can avoid this & future breakage, if we
do a negative check for the old syntax, instead of a positive
check for the new syntax

* src/qemu/qemu_conf.c: Invert cache option check
---
 src/qemu/qemu_conf.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/src/qemu/qemu_conf.c b/src/qemu/qemu_conf.c
index 0dbab48..db60ca3 100644
--- a/src/qemu/qemu_conf.c
+++ b/src/qemu/qemu_conf.c
@@ -1170,7 +1170,8 @@ static unsigned long long qemudComputeCmdFlags(const char 
*help,
 flags |= QEMUD_CMD_FLAG_DOMID;
 if (strstr(help, "-drive")) {
 flags |= QEMUD_CMD_FLAG_DRIVE;
-if (strstr(help, "cache=writethrough|writeback|none"))
+if (strstr(help, "cache=") &&
+!strstr(help, "cache=on|off"))
 flags |= QEMUD_CMD_FLAG_DRIVE_CACHE_V2;
 if (strstr(help, "format="))
 flags |= QEMUD_CMD_FLAG_DRIVE_FORMAT;
-- 
1.7.1.1

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

Re: [libvirt] [PATCH] qemu: Allow setting boot menu on/off

2010-07-27 Thread Daniel P. Berrange

On Mon, Jul 26, 2010 at 04:31:23PM -0400, Cole Robinson wrote:
> Add a new element to the  block:
> 
>   
> 
> Which maps to -boot,menu=on|off on the QEMU command line.
> 
> I decided to use an explicit 'enable' attribute rather than just make the
> bootmenu element boolean. This allows us to treat lack of a bootmenu element
> as 'use hypervisor default'.
> 
> Signed-off-by: Cole Robinson 

I'm wondering what we should do if we need a further option
to turn on/off the PXE boot menus that SEABIOS now adds to
QEMU for each NIC. I guess that might be a separate 
 element within the  device so probably
wouldn't impact this modelling

Daniel
-- 
|: Red Hat, Engineering, London-o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org-o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

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

Re: [libvirt] [PATCH] docs: Link wiki FAQ to main page

2010-07-27 Thread Daniel P. Berrange

On Mon, Jul 26, 2010 at 04:31:22PM -0400, Cole Robinson wrote:
> Since DV recommended keeping the build instructions distributed with the
> source, move them from the old FAQ to the downloads page.
> 
> Signed-off-by: Cole Robinson 
> ---
>  docs/FAQ.html.in   |  144 
> 
>  docs/Makefile.am   |3 +-
>  docs/downloads.html.in |   29 ++
>  docs/search.php|2 +-
>  docs/sitemap.html.in   |2 +-
>  5 files changed, 32 insertions(+), 148 deletions(-)
>  delete mode 100644 docs/FAQ.html.in


ACK


Daniel
-- 
|: Red Hat, Engineering, London-o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org-o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

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

Re: [libvirt] [PATCH] qemu: Error on unsupported graphics config

2010-07-27 Thread Daniel P. Berrange

On Mon, Jul 26, 2010 at 04:31:21PM -0400, Cole Robinson wrote:
> Throw an explicit error if multiple graphics devices are specified, or
> an unsupported type is specified (rdp).
> 
> Signed-off-by: Cole Robinson 
> ---
>  src/qemu/qemu_conf.c |   12 
>  1 files changed, 12 insertions(+), 0 deletions(-)
> 
> diff --git a/src/qemu/qemu_conf.c b/src/qemu/qemu_conf.c
> index 0dbab48..05ad67d 100644
> --- a/src/qemu/qemu_conf.c
> +++ b/src/qemu/qemu_conf.c
> @@ -4542,6 +4542,12 @@ int qemudBuildCommandLine(virConnectPtr conn,
>  }
>  }
>  
> +if (def->ngraphics > 1) {
> +qemuReportError(VIR_ERR_INTERNAL_ERROR,
> +"%s", _("only 1 graphics device is supported"));
> +goto error;
> +}
> +
>  if ((def->ngraphics == 1) &&
>  def->graphics[0]->type == VIR_DOMAIN_GRAPHICS_TYPE_VNC) {
>  virBuffer opt = VIR_BUFFER_INITIALIZER;
> @@ -4641,6 +4647,12 @@ int qemudBuildCommandLine(virConnectPtr conn,
>   * default, since the default changes :-( */
>  if (qemuCmdFlags & QEMUD_CMD_FLAG_SDL)
>  ADD_ARG_LIT("-sdl");
> +
> +} else if ((def->ngraphics == 1)) {
> +qemuReportError(VIR_ERR_INTERNAL_ERROR,
> +_("unsupported graphics type '%s'"),
> +virDomainGraphicsTypeToString(def->graphics[0]->type));
> +goto error;
>  }
>  
>  if (def->nvideos) {

ACK

Daniel
-- 
|: Red Hat, Engineering, London-o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org-o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

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

Re: [libvirt] [PATCH 4/5] domain conf: Support multiple devices

2010-07-27 Thread Daniel P. Berrange

On Mon, Jul 26, 2010 at 03:11:36PM -0400, Cole Robinson wrote:
> On 07/19/2010 11:42 AM, Daniel P. Berrange wrote:
> > On Wed, Jul 14, 2010 at 03:44:55PM -0400, Cole Robinson wrote:
> >> Change console handling to a proper device list, as done for other
> >> character devices. Even though certain drivers can actually handle multiple
> >> consoles, for now just maintain existing behavior where possible.
> >>
> >> Signed-off-by: Cole Robinson 
> > 
> > [snip]
> > 
> >> -chr->target.port = 0;
> >> -/*
> >> - * For HVM console actually created a serial device
> >> - * while for non-HVM it was a parvirt console
> >> - */
> >> -if (STREQ(def->os.type, "hvm")) {
> >> -if (def->nserials != 0) {
> >> -virDomainChrDefFree(chr);
> >> -} else {
> >> -if (VIR_ALLOC_N(def->serials, 1) < 0) {
> >> +chr->target.port = i;
> >> +
> >> +/* Back compat handling for the first console device */
> >> +if (i == 0) {
> >> +/*
> >> +* For HVM console actually created a serial device
> >> +* while for non-HVM it was a parvirt console
> >> +*/
> >> +if (STREQ(def->os.type, "hvm")) {
> >> +if (def->nserials != 0) {
> >>  virDomainChrDefFree(chr);
> >> -goto no_memory;
> >> +} else {
> >> +if (VIR_ALLOC_N(def->serials, 1) < 0) {
> >> +virDomainChrDefFree(chr);
> >> +goto no_memory;
> >> +}
> >> +def->nserials = 1;
> >> +def->serials[0] = chr;
> >> +chr->deviceType = VIR_DOMAIN_CHR_DEVICE_TYPE_SERIAL;
> >>  }
> >> -def->nserials = 1;
> >> -def->serials[0] = chr;
> >> -chr->deviceType = VIR_DOMAIN_CHR_DEVICE_TYPE_SERIAL;
> >> +} else {
> >> +def->consoles[def->nconsoles++] = chr;
> >>  }
> >>  } else {
> >> -def->console = chr;
> >> +def->consoles[def->nconsoles++] = chr;
> >>  }
> >>  }
> > 
> > This is where we get into a bit of a mess with back compatability,
> > when combined with the later DefFormat code.
> > 
> > The original requirement is that a  element generates
> > a  element for HVM guests. In the original code we throw
> > away the virDomainChrDef for the console, since we re-generate
> > it at format time if nconsoles==0.  This hack can't work anymore
> > with multiple consoles. Since if we have 2 consoles in the XML
> > and throw away console 0, we have nconsoles==1 during DefFormat
> > and thus won't re-generate the original console 0. To further
> > complicate life, we don't want todo any of this  compat
> > code this at all if console 0 is a virtio console.
> > 
> > 
> >> @@ -5496,9 +5512,10 @@ virDomainChrDefFormat(virBufferPtr buf,
> >>  return -1;
> >>  }
> >>  
> >> -/* Compat with legacy   syntax */
> >>  virBufferVSprintf(buf, "<%s type='%s'",
> >>elementName, type);
> >> +
> >> +/* Compat with legacy   syntax */
> >>  if (def->deviceType == VIR_DOMAIN_CHR_DEVICE_TYPE_CONSOLE &&
> >>  def->type == VIR_DOMAIN_CHR_TYPE_PTY &&
> >>  !(flags & VIR_DOMAIN_XML_INACTIVE) &&
> > 
> > Since we're allowing multiple  now, we should restrict this
> > hack to just the first one.
> > 
> >> @@ -6213,9 +6230,10 @@ char *virDomainDefFormat(virDomainDefPtr def,
> >>  goto cleanup;
> >>  
> >>  /* If there's a PV console that's preferred.. */
> >> -if (def->console) {
> >> -if (virDomainChrDefFormat(&buf, def->console, flags) < 0)
> >> -goto cleanup;
> >> +if (def->nconsoles) {
> >> +for (n = 0 ; n < def->nconsoles ; n++)
> >> +if (virDomainChrDefFormat(&buf, def->consoles[n], flags) < 0)
> >> +goto cleanup;
> >>  } else if (def->nserials != 0) {
> >>  /* ..else for legacy compat duplicate the first serial device as a
> >>   * console */
> > 
> > This logic can't work anymore.
> > 
> > 
> > What I think we need todo is to remove the hacks in both the Parse and
> > Format methods.  Then add one single hack for the parse method which
> > simply adds a matching  device if nserial==0 and the console
> > device type is serial. 
> > 
> 
> I poked at this for a while, and it's a big pain. Adding a single hack
> in the XML parse step isn't enough, because drivers like xen and esx
> build up a domain def manually in certain cases, so wouldn't gain the
> benefit of a hack in the parse function.

Can't we just manually add an equivalent hack in those drivers where
necessary ? We used to that in Xen in the past at least.


Daniel
-- 
|: Red Hat, Engineering, London-o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.o

Re: [libvirt] [PATCH 1/5] virt-aa-helper: Ignore open errors again

2010-07-27 Thread Daniel P. Berrange

On Tue, Jul 27, 2010 at 11:46:34AM +0200, Matthias Bolte wrote:
> 2010/7/26 Daniel P. Berrange :
> > On Sat, Jul 24, 2010 at 12:28:11AM +0200, Jamie Strandboge wrote:
> >> On Fri, 2010-07-23 at 19:24 +0200, Matthias Bolte wrote:
> >> > virt-aa-helper used to ignore errors when opening files.
> >> > Commit a8853344994a7c6aaca882a5e949ab5536821ab5 refactored
> >> > the related code and changed this behavior. virt-aa-helper
> >> > didn't ignore open errors anymore and virt-aa-helper-test
> >> > fails.
> >> >
> >> > Make sure that virt-aa-helper ignores open errors again.
> >> > ---
> >> >  src/security/virt-aa-helper.c |    2 +-
> >> >  1 files changed, 1 insertions(+), 1 deletions(-)
> >> >
> >> > diff --git a/src/security/virt-aa-helper.c 
> >> > b/src/security/virt-aa-helper.c
> >> > index 521545d..16b1920 100644
> >> > --- a/src/security/virt-aa-helper.c
> >> > +++ b/src/security/virt-aa-helper.c
> >> > @@ -846,7 +846,7 @@ get_files(vahControl * ctl)
> >> >      for (i = 0; i < ctl->def->ndisks; i++) {
> >> >          int ret = virDomainDiskDefForeachPath(ctl->def->disks[i],
> >> >                                                
> >> > ctl->allowDiskFormatProbing,
> >> > -                                              false,
> >> > +                                              true,
> >> >                                                add_file_path,
> >> >                                                &buf);
> >> >          if (ret != 0)
> >>
> >> I'm not 100% sure on this one. I have been developing patches to adjust
> >> for the new behavior on older releases and I did some shuffling to get
> >> this to work with 'false'. I'm not ready to submit at this time, and
> >> won't be able to get to it until the week after next. If this blocks
> >> Matthias' work, then feel free to commit and I'll post with a different
> >> patch if needed. Otherwise, we can wait.
> >
> > What is the scenario in which 'false' breaks things ? We use 'false' for
> > the selinux driver already. The problem with 'true' is that it means the
> > user will never see potentially important errors.
> >
> > Regards,
> > Daniel
> 
> Maybe it's a problem that's triggered by the test only.
> 
> Passing 'false' makes virt-aa-helper-test fail for tests that involve
> non-existing files:
> 
> $ ./virt-aa-helper-test
> FAIL: exited with '1'
>   create (non-existent disk):  '--dryrun -c -u
> libvirt-----0123456789ab':
> FAIL: exited with '1'
>   replace (non-existent disk):  '--dryrun -r -u
> libvirt-----0123456789ab':
> 
> Here's the command that virt-aa-helper-test executes for the first failing 
> test:
> 
> $ LD_LIBRARY_PATH="../src/.libs/" ../src/virt-aa-helper --dryrun -c -u
> libvirt-----0123456789ab <
> /tmp/tmp.IFQ5dqTvp6/test.xml
> virt-aa-helper: warning: path does not exist, skipping file type checks
> virt-aa-helper: error: invalid VM definition

Hmm, this does look like a test script bug. It should at least touch
the files so they exist before running. If a real deployment you would
actually want these kind of error messages about non-existant files.


Daniel
-- 
|: Red Hat, Engineering, London-o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org-o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

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

Re: [libvirt] [PATCH 1/5] virt-aa-helper: Ignore open errors again

2010-07-27 Thread Matthias Bolte

2010/7/26 Daniel P. Berrange :
> On Sat, Jul 24, 2010 at 12:28:11AM +0200, Jamie Strandboge wrote:
>> On Fri, 2010-07-23 at 19:24 +0200, Matthias Bolte wrote:
>> > virt-aa-helper used to ignore errors when opening files.
>> > Commit a8853344994a7c6aaca882a5e949ab5536821ab5 refactored
>> > the related code and changed this behavior. virt-aa-helper
>> > didn't ignore open errors anymore and virt-aa-helper-test
>> > fails.
>> >
>> > Make sure that virt-aa-helper ignores open errors again.
>> > ---
>> >  src/security/virt-aa-helper.c |    2 +-
>> >  1 files changed, 1 insertions(+), 1 deletions(-)
>> >
>> > diff --git a/src/security/virt-aa-helper.c b/src/security/virt-aa-helper.c
>> > index 521545d..16b1920 100644
>> > --- a/src/security/virt-aa-helper.c
>> > +++ b/src/security/virt-aa-helper.c
>> > @@ -846,7 +846,7 @@ get_files(vahControl * ctl)
>> >      for (i = 0; i < ctl->def->ndisks; i++) {
>> >          int ret = virDomainDiskDefForeachPath(ctl->def->disks[i],
>> >                                                ctl->allowDiskFormatProbing,
>> > -                                              false,
>> > +                                              true,
>> >                                                add_file_path,
>> >                                                &buf);
>> >          if (ret != 0)
>>
>> I'm not 100% sure on this one. I have been developing patches to adjust
>> for the new behavior on older releases and I did some shuffling to get
>> this to work with 'false'. I'm not ready to submit at this time, and
>> won't be able to get to it until the week after next. If this blocks
>> Matthias' work, then feel free to commit and I'll post with a different
>> patch if needed. Otherwise, we can wait.
>
> What is the scenario in which 'false' breaks things ? We use 'false' for
> the selinux driver already. The problem with 'true' is that it means the
> user will never see potentially important errors.
>
> Regards,
> Daniel

Maybe it's a problem that's triggered by the test only.

Passing 'false' makes virt-aa-helper-test fail for tests that involve
non-existing files:

$ ./virt-aa-helper-test
FAIL: exited with '1'
  create (non-existent disk):  '--dryrun -c -u
libvirt-----0123456789ab':
FAIL: exited with '1'
  replace (non-existent disk):  '--dryrun -r -u
libvirt-----0123456789ab':

Here's the command that virt-aa-helper-test executes for the first failing test:

$ LD_LIBRARY_PATH="../src/.libs/" ../src/virt-aa-helper --dryrun -c -u
libvirt-----0123456789ab <
/tmp/tmp.IFQ5dqTvp6/test.xml
virt-aa-helper: warning: path does not exist, skipping file type checks
virt-aa-helper: error: invalid VM definition

Here's the content of /tmp/tmp.IFQ5dqTvp6/test.xml


  virt-aa-helper-test
  ----0123456789ab
  524288
  524288
  1
  
hvm

  
  

  
  
  destroy
  restart
  destroy
  
/usr/bin/kvm

  
  
  


  
  
  





  

  


I noticed that this failed because the rewrite to use
virDomainDiskDefForeachPath changed the handling of non-existing
files. So I changed it back. That might not be the proper solution,
but it works. I seems that Jamie is working on a better solution for
that case.

Matthias

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

41 matches

Mail list logo