true, will add a element called acceleration/ cause there are some
features for 2d acceleration as well, so that will take care of 3d and 2d
acceleration both.
will post a patch soon with the above changes in it.
Reposting the patch with changes mentioned above.
Regards,
Pritesh
commit
On Thursday 13 August 2009 20:50:25 Daniel P. Berrange wrote:
On Mon, Aug 10, 2009 at 01:55:03PM +0200, Pritesh Kothari wrote:
Hi All,
I have added support for defining/dumping video device in VirtualBox. The
patch for the same is attached here. Also this patch depends on the
earlier
On Sun, Aug 16, 2009 at 10:47:54PM +0200, Miloslav Trmač wrote:
This patch adds a secret as a separately managed object, using a
special-purpose API to transfer the secret values between nodes and
libvirt users.
Okay, interesting...
Rather than add explicit accessors for attributes of
On Wed, Aug 19, 2009 at 11:21:58AM +0200, Daniel Veillard wrote:
On Sun, Aug 16, 2009 at 10:47:54PM +0200, Miloslav Trma?? wrote:
This patch adds a secret as a separately managed object, using a
special-purpose API to transfer the secret values between nodes and
libvirt users.
Okay,
- Daniel Veillard veill...@redhat.com wrote:
On Sun, Aug 16, 2009 at 10:47:54PM +0200, Miloslav Trmač wrote:
Rather than add explicit accessors for attributes of secrets, and
hard-code the secrets are related to storage volumes association
in
the API, the API uses XML to manipulate the
Hello,
I am currently investigating the possibility to implement MAC address
based filtering in libvirt and was wondering if there is any related
effort going on and what people in general would think about that.
Here is a description of my current prototype implementation:
I have a small setup
On Wed, Aug 19, 2009 at 02:11:14PM +0200, Gerhard Stenzel wrote:
Hello,
I am currently investigating the possibility to implement MAC address
based filtering in libvirt and was wondering if there is any related
effort going on and what people in general would think about that.
Great, we
On Wed, 2009-08-19 at 13:35 +0100, Daniel P. Berrange wrote:
On Wed, Aug 19, 2009 at 02:11:14PM +0200, Gerhard Stenzel wrote:
...
I think this extra XML element is probably redundant - we should always do
MAC filtering at all times, on all bridges. Not simply those used in a
virtual network,
On Wed, Aug 19, 2009 at 10:34:38AM +0100, Daniel P. Berrange wrote:
On Wed, Aug 19, 2009 at 11:21:58AM +0200, Daniel Veillard wrote:
On Sun, Aug 16, 2009 at 10:47:54PM +0200, Miloslav Trma?? wrote:
This patch adds a secret as a separately managed object, using a
special-purpose API to
On Wed, Aug 19, 2009 at 05:36:27AM -0400, Miloslav Trmac wrote:
- Daniel Veillard veill...@redhat.com wrote:
On Sun, Aug 16, 2009 at 10:47:54PM +0200, Miloslav Trmač wrote:
Rather than add explicit accessors for attributes of secrets, and
hard-code the secrets are related to storage
On Fri, Jul 24, 2009 at 11:44 PM, Anton Protopopovasp...@gmail.com wrote:
2009/7/24 Daniel P. Berrange berra...@redhat.com
We should make use of this --name parameter then - I guess it didn't
exist when we first wrote the driver. It is useful to users to have
separate ID vs Name parameters -
On Wed, Aug 19, 2009 at 05:36:27AM -0400, Miloslav Trmac wrote:
- Daniel Veillard veill...@redhat.com wrote:
+virSecretPtrvirSecretDefineXML (virConnectPtr conn,
+ const char *xml);
Let's add an unsigned int flags
FYI, I just pushed the following patch to the repo which adds documentation
to the website for all the security model related aspects of libvirt's
QEMU driver. It should appear here shortly
http://libvirt.org/drvqemu.html
Regards,
Daniel
diff --git a/docs/drvqemu.html.in
On Sun, Aug 16, 2009 at 10:47:56PM +0200, Miloslav Trmač wrote:
Changes since the second submission:
- Update for the changed public API
- s/secret_id/uuid/g
- use unsigned char * for secret value
[...]
+/**
+ * virConnectListSecrets:
+ * @conn: virConnect connection
+ * @uuids: Pointer to
On Sun, Aug 16, 2009 at 10:47:58PM +0200, Miloslav Trmač wrote:
Changes since the second submission:
- Update for the changed public API
- s/secret_id/uuid/g
- use unsigned char * for secret value
---
src/datatypes.h |1 +
src/remote_internal.c | 323
On Sun, Aug 16, 2009 at 10:47:59PM +0200, Miloslav Trmač wrote:
Changes since the second submission:
- Update for the changed public API
- s/secret_id/uuid/g
- use unsigned char * for secret value
like for 04/20 , this will need some regeneration for the new flags
args but otherwise fine
- Daniel Veillard veill...@redhat.com wrote:
On Sun, Aug 16, 2009 at 10:47:55PM +0200, Miloslav Trmač wrote:
/**
+ * virSecretFreeName:
+ * @secret_: a secret object
+ *
+ * Destroy the vol object, this is just used by the vol hash callback.
+ * Returns 0 in case of success and
- Daniel Veillard veill...@redhat.com wrote:
On Sun, Aug 16, 2009 at 10:47:58PM +0200, Miloslav Trmač wrote:
+static virDrvOpenStatus
+remoteSecretOpen (virConnectPtr conn,
+ virConnectAuthPtr auth,
+ int flags)
+{
+if (inside_daemon)
+
On Wed, Aug 19, 2009 at 09:49:45AM -0400, Miloslav Trmac wrote:
- Daniel Veillard veill...@redhat.com wrote:
On Sun, Aug 16, 2009 at 10:47:58PM +0200, Miloslav Trma?? wrote:
+static virDrvOpenStatus
+remoteSecretOpen (virConnectPtr conn,
+ virConnectAuthPtr auth,
On Wed, 2009-08-19 at 14:32 +0100, Daniel P. Berrange wrote:
FYI, I just pushed the following patch to the repo which adds documentation
to the website for all the security model related aspects of libvirt's
QEMU driver. It should appear here shortly
http://libvirt.org/drvqemu.html
Looks
On Sun, Aug 16, 2009 at 10:48:00PM +0200, Miloslav Trmač wrote:
This implementation stores the secrets in an unencrypted text file,
for simplicity in implementation and debugging.
(Symmetric encryption, e.g. using gpgme, will not be difficult to add.
Because the TLS private key used by
On Sun, Aug 16, 2009 at 10:48:01PM +0200, Miloslav Trmač wrote:
Changes since the second submission:
- Change some command names to better follow the conventions
- Update for the changed public API
- Print (potentially auto-generated) secret UUID on successful
secret-define
-
On Sun, Aug 16, 2009 at 10:48:02PM +0200, Miloslav Trmač wrote:
This commit represents results of (make -C docs api) - if this patch
does not apply, just re-run the command.
The API data gathered by this commit is necessary to make step 10 (Python
bindings) usable.
Okay, I usually don't
- Daniel Veillard veill...@redhat.com wrote:
On Sun, Aug 16, 2009 at 10:48:00PM +0200, Miloslav Trmač wrote:
This implementation stores the secrets in an unencrypted text file,
for simplicity in implementation and debugging.
(Symmetric encryption, e.g. using gpgme, will not be
On Sun, Aug 16, 2009 at 10:48:03PM +0200, Miloslav Trmač wrote:
okay,
@@ -714,6 +725,12 @@ def nameFixup(name, classe, type, file):
elif name[0:18] == virInterfaceLookup:
func = name[3:]
func = string.lower(func[0:1]) + func[1:]
+elif name[0:15] ==
On Mon, Aug 17, 2009 at 12:37:31PM +0200, Chris Lalancette wrote:
Fix up a small memory leak pointed out by DanB; I was forgetting
to release memory allocated to driver-saveImageFormat.
Also add the save_image_format and security entries to
the augeas lens.
ACK !
Daniel
--
Daniel
On Wednesday 19 August 2009 10:01:59 Mark McLoughlin wrote:
+h3a name=securitydacPOSIX DAC users/groups/a/h3
+
+p
+ In the session instance, the POSIX DAC model restricts QEMU
virtual
Should expand the acronym, it's pretty obscure
I agree ... DAC and MAC are terms of art
On Sun, Aug 16, 2009 at 10:47:54PM +0200, Miloslav Trma?? wrote:
This patch adds a secret as a separately managed object, using a
special-purpose API to transfer the secret values between nodes and
libvirt users.
Rather than add explicit accessors for attributes of secrets, and
hard-code
On Wed, Aug 19, 2009 at 03:01:59PM +0100, Mark McLoughlin wrote:
On Wed, 2009-08-19 at 14:32 +0100, Daniel P. Berrange wrote:
FYI, I just pushed the following patch to the repo which adds documentation
to the website for all the security model related aspects of libvirt's
QEMU driver. It
Dave Allan wrote:
Daniel P. Berrange wrote:
On Thu, Jul 23, 2009 at 02:53:48PM -0400, Dave Allan wrote:
Daniel P. Berrange wrote:
It doesn't currently allow configuration of multipathing, so for
now setting the multipath configuration will have to continue to be
done as part of the host
30 matches
Mail list logo
