- Devel - libvirt List Archives

[libvirt] [PATCH] build: distribute 'make syntax-check' tweaks
by Eric Blake 09 Feb '11

09 Feb '11

* Makefile.am (EXTRA_DIST): Distribute cfg.mk. --- I noticed that the 0.8.7 tarball lacks cfg.mk, so running 'make syntax-check' on that tarball is bound to have problems (without that file, you don't exempt tests in gnulib's maint.mk that libvirt is not interested in, and you miss out on lots of other tests that are libvirt-specific). Tested with 'make distcheck', then inspecting the resulting tarball. I almost pushed this under a trivial rule, but restrained myself to wait for a proper review. :) Makefile.am | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/Makefile.am b/Makefile.am index 597ec61..882e676 100644 --- a/Makefile.am +++ b/Makefile.am @@ -51,6 +51,7 @@ EXTRA_DIST = \ autobuild.sh \ Makefile.nonreentrant \ autogen.sh \ + cfg.mk \ examples/domain-events/events-python \ $(syntax_check_exceptions) \ $(XML_EXAMPLES) -- 1.7.3.5

2 3

[libvirt] [PATCH] maint: whitespace cleanup
by Eric Blake 09 Feb '11

09 Feb '11

* cfg.mk (sc_TAB_in_indentation): Check more files. * .dir-locals.el (html-mode): Let emacs help out. * docs/internals/command.html.in: Fix offenders. * docs/formatdomain.html.in: Likewise. * docs/internals.html.in: Likewise. Reported by Jiri Denemark. --- Here's the git diff -b output; actual patch below the diffstat. diff --git c/.dir-locals.el w/.dir-locals.el index 7c483d2..f24ec61 100644 --- c/.dir-locals.el +++ w/.dir-locals.el @@ -5,4 +5,7 @@ (c-indent-level . 4) (c-basic-offset . 4) )) + (html-mode . ( + (indent-tabs-mode . nil) + )) ) diff --git c/cfg.mk w/cfg.mk index 7664bdf..120f452 100644 --- c/cfg.mk +++ w/cfg.mk @@ -322,13 +322,13 @@ sc_prohibit_ctype_h: halt="don't use ctype.h; instead, use c-ctype.h" \ $(_sc_search_regexp) -# Ensure that no C source file or rng schema uses TABs for +# Ensure that no C source file, docs, or rng schema uses TABs for # indentation. Also match *.h.in files, to get libvirt.h.in. Exclude # files in gnulib, since they're imported. sc_TAB_in_indentation: @prohibit='^ * ' \ - in_vc_files='(\.(rng|[ch](\.in)?)|(daemon|tools)/.*\.in)$$' \ - halt='use spaces, not TAB, for indentation in C, sh, and RNG schemas' \ + in_vc_files='(\.(rng|[ch](\.in)?|html.in)|(daemon|tools)/.*\.in)$$' \ + halt='use leading spaces, not TAB, in C, sh, html, and RNG schemas' \ $(_sc_search_regexp) ctype_re = isalnum|isalpha|isascii|isblank|iscntrl|isdigit|isgraph|islower\ .dir-locals.el | 3 + cfg.mk | 6 +- docs/formatdomain.html.in | 224 ++++++++++++++++++++-------------------- docs/internals.html.in | 4 +- docs/internals/command.html.in | 32 +++--- 5 files changed, 136 insertions(+), 133 deletions(-) diff --git a/.dir-locals.el b/.dir-locals.el index 7c483d2..f24ec61 100644 --- a/.dir-locals.el +++ b/.dir-locals.el @@ -5,4 +5,7 @@ (c-indent-level . 4) (c-basic-offset . 4) )) + (html-mode . ( + (indent-tabs-mode . nil) + )) ) diff --git a/cfg.mk b/cfg.mk index 7664bdf..120f452 100644 --- a/cfg.mk +++ b/cfg.mk @@ -322,13 +322,13 @@ sc_prohibit_ctype_h: halt="don't use ctype.h; instead, use c-ctype.h" \ $(_sc_search_regexp) -# Ensure that no C source file or rng schema uses TABs for +# Ensure that no C source file, docs, or rng schema uses TABs for # indentation. Also match *.h.in files, to get libvirt.h.in. Exclude # files in gnulib, since they're imported. sc_TAB_in_indentation: @prohibit='^ * ' \ - in_vc_files='(\.(rng|[ch](\.in)?)|(daemon|tools)/.*\.in)$$' \ - halt='use spaces, not TAB, for indentation in C, sh, and RNG schemas' \ + in_vc_files='(\.(rng|[ch](\.in)?|html.in)|(daemon|tools)/.*\.in)$$' \ + halt='use leading spaces, not TAB, in C, sh, html, and RNG schemas' \ $(_sc_search_regexp) ctype_re = isalnum|isalpha|isascii|isblank|iscntrl|isdigit|isgraph|islower\ diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in index 43c78fc..b048bb5 100644 --- a/docs/formatdomain.html.in +++ b/docs/formatdomain.html.in @@ -304,20 +304,20 @@ omitted, it defaults to the OS provided defaults.</dd> <dt><code>hard_limit</code></dt> <dd> The optional <code>hard_limit</code> element is the maximum memory - the guest can use. The units for this value are kilobytes (i.e. blocks - of 1024 bytes)</dd> + the guest can use. The units for this value are kilobytes (i.e. blocks + of 1024 bytes)</dd> <dt><code>soft_limit</code></dt> <dd> The optional <code>soft_limit</code> element is the memory limit to - enforce during memory contention. The units for this value are - kilobytes (i.e. blocks of 1024 bytes)</dd> + enforce during memory contention. The units for this value are + kilobytes (i.e. blocks of 1024 bytes)</dd> <dt><code>swap_hard_limit</code></dt> <dd> The optional <code>swap_hard_limit</code> element is the maximum - swap the guest can use. The units for this value are kilobytes - (i.e. blocks of 1024 bytes)</dd> + swap the guest can use. The units for this value are kilobytes + (i.e. blocks of 1024 bytes)</dd> <dt><code>min_guarantee</code></dt> <dd> The optional <code>min_guarantee</code> element is the guaranteed - minimum memory allocation for the guest. The units for this value are - kilobytes (i.e. blocks of 1024 bytes)</dd> + minimum memory allocation for the guest. The units for this value are + kilobytes (i.e. blocks of 1024 bytes)</dd> <dt><code>vcpu</code></dt> <dd>The content of this element defines the maximum number of virtual CPUs allocated for the guest OS, which must be between 1 and @@ -387,8 +387,8 @@ match the specification.</dd> </dl> - <span class="since">Since 0.8.5</span> the <code>match</code> - attribute can be omitted and will default to <code>exact</code>. + <span class="since">Since 0.8.5</span> the <code>match</code> + attribute can be omitted and will default to <code>exact</code>. </dd> <dt><code>model</code></dt> @@ -436,8 +436,8 @@ CPU.</dd> </dl> - <span class="since">Since 0.8.5</span> the <code>policy</code> - attribute can be omitted and will default to <code>require</code>. + <span class="since">Since 0.8.5</span> the <code>policy</code> + attribute can be omitted and will default to <code>require</code>. </dd> </dl> @@ -566,101 +566,101 @@ <dl> <dt><code>clock</code></dt> <dd> - <p>The <code>offset</code> attribute takes four possible - values, allowing fine grained control over how the guest - clock is synchronized to the host. NB, not all hypervisors - support all modes.</p> - <dl> - <dt><code>utc</code></dt> - <dd> - The guest clock will always be synchronized to UTC when - booted</dd> - <dt><code>localtime</code></dt> - <dd> - The guest clock will be synchronized to the host's configured - timezone when booted, if any. - </dd> - <dt><code>timezone</code></dt> - <dd> - The guest clock will be synchronized to the requested timezone - using the <code>timezone</code> attribute. - <span class="since">Since 0.7.7</span> - </dd> - <dt><code>variable</code></dt> - <dd> - The guest clock will have an arbitrary offset applied - relative to UTC. The delta relative to UTC is specified - in seconds, using the <code>adjustment</code> attribute. - The guest is free to adjust the RTC over time an expect - that it will be honoured at next reboot. This is in - contrast to 'utc' mode, where the RTC adjustments are - lost at each reboot. <span class="since">Since 0.7.7</span> - </dd> - </dl> - <p> - A <code>clock</code> may have zero or more - <code>timer</code>sub-elements. <span class="since">Since - 0.8.0</span> - </p> + <p>The <code>offset</code> attribute takes four possible + values, allowing fine grained control over how the guest + clock is synchronized to the host. NB, not all hypervisors + support all modes.</p> + <dl> + <dt><code>utc</code></dt> + <dd> + The guest clock will always be synchronized to UTC when + booted</dd> + <dt><code>localtime</code></dt> + <dd> + The guest clock will be synchronized to the host's configured + timezone when booted, if any. + </dd> + <dt><code>timezone</code></dt> + <dd> + The guest clock will be synchronized to the requested timezone + using the <code>timezone</code> attribute. + <span class="since">Since 0.7.7</span> + </dd> + <dt><code>variable</code></dt> + <dd> + The guest clock will have an arbitrary offset applied + relative to UTC. The delta relative to UTC is specified + in seconds, using the <code>adjustment</code> attribute. + The guest is free to adjust the RTC over time an expect + that it will be honoured at next reboot. This is in + contrast to 'utc' mode, where the RTC adjustments are + lost at each reboot. <span class="since">Since 0.7.7</span> + </dd> + </dl> + <p> + A <code>clock</code> may have zero or more + <code>timer</code>sub-elements. <span class="since">Since + 0.8.0</span> + </p> </dd> <dt><code>timer</code></dt> <dd> - <p> - Each timer element requires a <code>name</code> attribute, - and has other optional attributes that depend on - the <code>name</code> specified. Various hypervisors - support different combinations of attributes. - </p> - <dl> - <dt><code>name</code></dt> - <dd> - The <code>name</code> attribute selects which timer is - being modified, and can be one of "platform", "pit", - "rtc", "hpet", or "tsc". - </dd> - <dt><code>track</code></dt> - <dd> - The <code>track</code> attribute specifies what the timer - tracks, and can be "boot", "guest", or "wall". - Only valid for <code>name="rtc"</code> - or <code>name="platform"</code>. - </dd> - <dt><code>tickpolicy</code></dt> - <dd> - The <code>tickpolicy</code> attribute determines how - missed ticks in the guest are handled, and can be "delay", - "catchup", "merge", or "discard". If the policy is - "catchup", there can be further details in - the <code>catchup</code> sub-element. - <dl> - <dt><code>catchup</code></dt> - <dd> - The <code>catchup</code> element has three optional - attributes, each a positive integer. The attributes - are <code>threshold</code>, <code>slew</code>, - and <code>limit</code>. - </dd> - </dl> - </dd> - <dt><code>frequency</code></dt> - <dd> - The <code>frequency</code> attribute is an unsigned - integer specifying the frequency at - which <code>name="tsc"</code> runs. - </dd> - <dt><code>mode</code></dt> - <dd> - The <code>mode</code> attribute controls how - the <code>name="tsc"</code> timer is managed, and can be - "auto", "native", "emulate", "paravirt", or "smpsafe". - Other timers are always emulated. - </dd> - <dt><code>present</code></dt> - <dd> - The <code>present</code> attribute can be "yes" or "no" to - specify whether a particular timer is available to the guest. - </dd> - </dl> + <p> + Each timer element requires a <code>name</code> attribute, + and has other optional attributes that depend on + the <code>name</code> specified. Various hypervisors + support different combinations of attributes. + </p> + <dl> + <dt><code>name</code></dt> + <dd> + The <code>name</code> attribute selects which timer is + being modified, and can be one of "platform", "pit", + "rtc", "hpet", or "tsc". + </dd> + <dt><code>track</code></dt> + <dd> + The <code>track</code> attribute specifies what the timer + tracks, and can be "boot", "guest", or "wall". + Only valid for <code>name="rtc"</code> + or <code>name="platform"</code>. + </dd> + <dt><code>tickpolicy</code></dt> + <dd> + The <code>tickpolicy</code> attribute determines how + missed ticks in the guest are handled, and can be "delay", + "catchup", "merge", or "discard". If the policy is + "catchup", there can be further details in + the <code>catchup</code> sub-element. + <dl> + <dt><code>catchup</code></dt> + <dd> + The <code>catchup</code> element has three optional + attributes, each a positive integer. The attributes + are <code>threshold</code>, <code>slew</code>, + and <code>limit</code>. + </dd> + </dl> + </dd> + <dt><code>frequency</code></dt> + <dd> + The <code>frequency</code> attribute is an unsigned + integer specifying the frequency at + which <code>name="tsc"</code> runs. + </dd> + <dt><code>mode</code></dt> + <dd> + The <code>mode</code> attribute controls how + the <code>name="tsc"</code> timer is managed, and can be + "auto", "native", "emulate", "paravirt", or "smpsafe". + Other timers are always emulated. + </dd> + <dt><code>present</code></dt> + <dd> + The <code>present</code> attribute can be "yes" or "no" to + specify whether a particular timer is available to the guest. + </dd> + </dl> </dd> </dl> @@ -1490,7 +1490,7 @@ qemu-kvm -net nic,model=? /dev/null </dd> <dt><code>"spice"</code></dt> <dd> - <p> + <p> Starts a SPICE server. The <code>port</code> attribute specifies the TCP port number (with -1 as legacy syntax indicating that it should be auto-allocated), while <code>tlsPort</code> gives an alternative @@ -1502,8 +1502,8 @@ qemu-kvm -net nic,model=? /dev/null to use. It is possible to set a limit on the validity of the password be giving an timestamp <code>passwdValidTo='2010-04-09T15:51:00'</code> assumed to be in UTC. NB, this may not be supported by all hypervisors. - </p> - <p> + </p> + <p> When SPICE has both a normal and TLS secured TCP port configured, it can be desirable to restrict what channels can be run on each port. This is achieved by adding one or more <channel> elements inside @@ -1511,8 +1511,8 @@ qemu-kvm -net nic,model=? /dev/null <code>main</code>, <code>display</code>, <code>inputs</code>, <code>cursor</code>, <code>playback</code>, <code>record</code>; and <span class="since">since 0.8.8</span>: <code>smartcard</code>. - </p> - <pre> + </p> + <pre> <graphics type='spice' port='-1' tlsPort='-1' autoport='yes'> <channel name='main' mode='secure'/> <channel name='record' mode='insecure'/> @@ -1569,7 +1569,7 @@ qemu-kvm -net nic,model=? /dev/null <dd> The <code>model</code> element has a mandatory <code>type</code> attribute which takes the value "vga", "cirrus", "vmvga", "qxl", - "xen" or "vbox", depending on the hypervisor features available. + "xen" or "vbox", depending on the hypervisor features available. You can also provide the amount of video memory in kilobytes using <code>vram</code> and the number of screen with <code>heads</code>. </dd> @@ -2167,8 +2167,8 @@ qemu-kvm -net nic,model=? /dev/null <dd> <p> The required <code>model</code> attribute specifies what type - of balloon device is provided. Valid values are specific to - the virtualization platform + of balloon device is provided. Valid values are specific to + the virtualization platform </p> <ul> <li>'virtio' — default with QEMU/KVM</li> diff --git a/docs/internals.html.in b/docs/internals.html.in index dc88eab..6fa2de3 100644 --- a/docs/internals.html.in +++ b/docs/internals.html.in @@ -10,10 +10,10 @@ <ul> <li>Introduction to basic rules and guidelines for <a href="hacking.html">hacking<a> - on libvirt code</li> + on libvirt code</li> <li>Guide to adding <a href="api_extension.html">public APIs<a></li> <li>Approach for <a href="internals/command.html">spawning commands</a> from - libvirt driver code</li> + libvirt driver code</li> </ul> </body> diff --git a/docs/internals/command.html.in b/docs/internals/command.html.in index 95d2b81..27dcf9c 100644 --- a/docs/internals/command.html.in +++ b/docs/internals/command.html.in @@ -20,27 +20,27 @@ <ul> <li><code>fork+exec</code>: The lowest & most flexible - level, but very hard to use correctly / safely. It - is easy to leak file descriptors, have unexpected - signal handler behaviour and not handle edge cases. - Furthermore, it is not portable to mingw. - </li> + level, but very hard to use correctly / safely. It + is easy to leak file descriptors, have unexpected + signal handler behaviour and not handle edge cases. + Furthermore, it is not portable to mingw. + </li> <li><code>system</code>: Convenient if you don't care - about capturing command output, but has the serious - downside that the command string is interpreted by - the shell. This makes it very dangerous to use, because - improperly validated user input can lead to exploits - via shell meta characters. + about capturing command output, but has the serious + downside that the command string is interpreted by + the shell. This makes it very dangerous to use, because + improperly validated user input can lead to exploits + via shell meta characters. </li> <li><code>popen</code>: Inherits the flaws of - <code>system</code>, and has no option for bi-directional - communication. + <code>system</code>, and has no option for bi-directional + communication. </li> <li><code>posix_spawn</code>: A half-way house between - simplicity of system() and the flexibility of fork+exec. - It does not allow for a couple of important features - though, such as running a hook between the fork+exec - stage, or closing all open file descriptors.</li> + simplicity of system() and the flexibility of fork+exec. + It does not allow for a couple of important features + though, such as running a hook between the fork+exec + stage, or closing all open file descriptors.</li> </ul> <p> -- 1.7.4

2 3

[libvirt] [PATCH libvirt-site v2] Add information about libvirt-php new location [was Change PHP binding link to new one hosted on libvirt.org]
by Michal Novotny 09 Feb '11

09 Feb '11

Signed-off-by: Michal Novotny <minovotn(a)redhat.com> --- docs/bindings.html.in | 8 +++--- docs/php.html.in | 57 ++---------------------------------------------- 2 files changed, 7 insertions(+), 58 deletions(-) diff --git a/docs/bindings.html.in b/docs/bindings.html.in index 87d894d..2d936a0 100644 --- a/docs/bindings.html.in +++ b/docs/bindings.html.in @@ -28,16 +28,16 @@ <li> <p> <strong>PHP</strong>: Radek Hladik started developing - <a href="http://phplibvirt.cybersales.cz/">PHP bindings</a> in 2010. + <a href="http://libvirt.org/php">PHP bindings</a> in 2010. </p> <p> - In February 2011 the binding development has been moved to the - <a href="http://libvirt.org/git/?p=libvirt-php.git;a=summary">libvirt.org as libvirt-php project</a>. + In February 2011 the binding development has been moved to the libvirt.org website as + libvirt-php project. </p> <p> The project is now maintained by Michal Novotny and it's heavily based on Radek's version. For more information including the information on posting - the patches you to libvirt-php please refer to <a href="php.html">PHP binding page</a>. + the patches you to libvirt-php please refer to <a href="http://libvirt.org/php">PHP binding</a>. </p> </li> <li> diff --git a/docs/php.html.in b/docs/php.html.in index ea4f76a..5283e67 100644 --- a/docs/php.html.in +++ b/docs/php.html.in @@ -24,60 +24,9 @@ It can also be browsed at </pre> <p></p> -<h2>Building</h2> -<p>The code is using autotools to generate the files necessary for compilation. The preferred way of building is - to run autogen.sh to generate configure script and then go on with the standard linux make commands, i.e.</p> - -<pre> -$ cd libvirt-php -$ ./autogen.sh -$ make -</pre> - - -<h2>Enabling the module in PHP</h2> -<p>Before you start using the module you have to install the module first. The module -php_libvirt.so is being generated when you compile it. This is necessary to be loaded -in the extensions sections of php.ini file for PHP version older than PHP-5.</p> -<p> -Starting with PHP-5 you can create a file called libvirt.ini in /etc/php.d having just -one line <code>extension=php_libvirt.so</code> to enable the extension. Of course, you -need to have this module copied in the directory with the rest of your PHP modules to -make PHP find the module for you.</p> -<p> -If you're using PHP as a module (mod_php5.so) in the Apache webserver you need to -restart your Apache to trigger configuration reload for PHP. -</p> -<p> -If you're not sure that you have everything set up right and you don't want to restart -your Apache webserver before you're sure everything will be working fine you could try -running the test using cli-based PHP interpreter. There are some example scripts coming -along the source codes in the <code>example</code> subdirectory so you can try to run -php on the index.php script to check whether it's working fine to establish connection or not. -</p> -<p> -When you're having some issues with the connection make sure the apache user is having -access to libvirt. For more information please see <a href="auth.html">Libvirt access control</a> page. -</p> -<h2>Contribution</h2> -<p> -If you would like to contribute to the libvirt-php project you could write patches for it but please -make sure you're following the procedure below: - -<ol> - <li>Sign up to libvirt list if you're not on it yet (libvir-list(a)redhat.com)</li> - <li>Clone the repository from libvirt.org site using: - <pre>git clone git://libvirt.org/libvirt-php</pre> - </li> - <li>Set your git username and e-mail and also set the subject prefix in the project's repository using: - <pre>git config --local format.subjectprefix "libvirt-php"</pre> - </li> - <li>Create the patch in the form of the commits and include also information about usage (example source codes maybe) and testing</li> - <li>Format it using <code>git format-patch -X</code> where X is the number of patch parts to be posted, for multipart patch (X is greater than 1) please use also numbering (-n) option and include the cover-letter (--cover-letter).</li> - <li>Send to libvir-list(a)redhat.com using the <code>git send-email <files> --to libvir-list(a)redhat.com</code> command where <files> can be <i>000*</i> to send all the patches formatted by git format-patch since git format-patch names the files starting with the 4 digit numbers.</li> -</ol> - -When you send the patch you're patch will be reviewed and later committed to the libvirt-php repository. You'll be contacted in case some flaws are found during the review. +<h2>Project pages</h2> +<p>Since February 2011 the project have it's own pages hosted at libvirt.org. For more information on the project + please refer to <a href="http://libvirt.org/php">http://libvirt.org/php</a>. </p> -- 1.7.3.2

1 0

[libvirt] [PATCH libvirt site] Change PHP binding link to new one hosted on libvirt.org
by Michal Novotny 09 Feb '11

09 Feb '11

Signed-off-by: Michal Novotny <minovotn(a)redhat.com> --- docs/bindings.html.in | 8 ++++---- docs/sitemap.html.in | 4 ---- 2 files changed, 4 insertions(+), 8 deletions(-) diff --git a/docs/bindings.html.in b/docs/bindings.html.in index 87d894d..2d936a0 100644 --- a/docs/bindings.html.in +++ b/docs/bindings.html.in @@ -28,16 +28,16 @@ <li> <p> <strong>PHP</strong>: Radek Hladik started developing - <a href="http://phplibvirt.cybersales.cz/">PHP bindings</a> in 2010. + <a href="http://libvirt.org/php">PHP bindings</a> in 2010. </p> <p> - In February 2011 the binding development has been moved to the - <a href="http://libvirt.org/git/?p=libvirt-php.git;a=summary">libvirt.org as libvirt-php project</a>. + In February 2011 the binding development has been moved to the libvirt.org website as + libvirt-php project. </p> <p> The project is now maintained by Michal Novotny and it's heavily based on Radek's version. For more information including the information on posting - the patches you to libvirt-php please refer to <a href="php.html">PHP binding page</a>. + the patches you to libvirt-php please refer to <a href="http://libvirt.org/php">PHP binding</a>. </p> </li> <li> diff --git a/docs/sitemap.html.in b/docs/sitemap.html.in index ac0af71..c987c49 100644 --- a/docs/sitemap.html.in +++ b/docs/sitemap.html.in @@ -266,10 +266,6 @@ <a href="csharp.html">C#</a> <span>overview of the C# API bindings</span> </li> - <li> - <a href="php.html">PHP</a> - <span>overview of the PHP API bindings</span> - </li> </ul> </li> <li> -- 1.7.3.2

2 4

Re: [libvirt] [virt-tools-list] difference between blkid of a system and uuid of virtual machine by virt-manager
by Cole Robinson 09 Feb '11

09 Feb '11

On 02/08/2011 02:06 PM, Tapas Mishra wrote: > I want to know what is the difference between the output blkid command > shows and the uuid which is set by virt-manager > while creating a guest. > Suppose in case of a re installation sort of situation I want to do a > fresh install and restore things from a backup then > where does this UUID thing comes into picture and what is its role > with respect to Virtual Machines. > > AFAIU it's just a unique identifier for use with libvirt, though nowadays it might be passed down to the guest for other purposes. cc-ing libvirt-list - Cole

1 0

[libvirt] [PATCH] Adjust some log levels in udev driver
by Daniel P. Berrange 09 Feb '11

09 Feb '11

Most of te VIR_INFO calls in the udev driver are only relevant to developers so can switch to VIR_DEBUG. Failure to initialize libpciaccess though is a fatal error * src/node_device/node_device_udev.c: Adjust log levels --- src/node_device/node_device_udev.c | 44 ++++++++++++++++++------------------ 1 files changed, 22 insertions(+), 22 deletions(-) diff --git a/src/node_device/node_device_udev.c b/src/node_device/node_device_udev.c index 93390af..475cbb5 100644 --- a/src/node_device/node_device_udev.c +++ b/src/node_device/node_device_udev.c @@ -116,8 +116,8 @@ static int udevGetDeviceProperty(struct udev_device *udev_device, udev_value = udev_device_get_property_value(udev_device, property_key); if (udev_value == NULL) { - VIR_INFO(_("udev reports device '%s' does not have property '%s'"), - udev_device_get_sysname(udev_device), property_key); + VIR_DEBUG("udev reports device '%s' does not have property '%s'", + udev_device_get_sysname(udev_device), property_key); ret = PROPERTY_MISSING; goto out; } @@ -205,8 +205,8 @@ static int udevGetDeviceSysfsAttr(struct udev_device *udev_device, udev_value = udev_device_get_sysattr_value(udev_device, attr_name); if (udev_value == NULL) { - VIR_INFO(_("udev reports device '%s' does not have sysfs attr '%s'"), - udev_device_get_sysname(udev_device), attr_name); + VIR_DEBUG("udev reports device '%s' does not have sysfs attr '%s'", + udev_device_get_sysname(udev_device), attr_name); ret = PROPERTY_MISSING; goto out; } @@ -950,9 +950,9 @@ static int udevKludgeStorageType(virNodeDeviceDefPtr def) { int ret = -1; - VIR_INFO("Could not find definitive storage type for device " - "with sysfs path '%s', trying to guess it", - def->sysfs_path); + VIR_DEBUG("Could not find definitive storage type for device " + "with sysfs path '%s', trying to guess it", + def->sysfs_path); if (STRPREFIX(def->caps->data.storage.block, "/dev/vd")) { /* virtio disk */ @@ -963,8 +963,8 @@ static int udevKludgeStorageType(virNodeDeviceDefPtr def) } if (ret != 0) { - VIR_INFO("Could not determine storage type for device " - "with sysfs path '%s'", def->sysfs_path); + VIR_DEBUG("Could not determine storage type for device " + "with sysfs path '%s'", def->sysfs_path); } else { VIR_DEBUG("Found storage type '%s' for device " "with sysfs path '%s'", @@ -1062,8 +1062,8 @@ static int udevProcessStorage(struct udev_device *device, } else if (STREQ(def->caps->data.storage.drive_type, "floppy")) { ret = udevProcessFloppy(device, def); } else { - VIR_INFO("Unsupported storage type '%s'", - def->caps->data.storage.drive_type); + VIR_DEBUG("Unsupported storage type '%s'", + def->caps->data.storage.drive_type); goto out; } @@ -1141,9 +1141,9 @@ static int udevGetDeviceType(struct udev_device *device, goto out; } - VIR_INFO("Could not determine device type for device " - "with sysfs path '%s'", - udev_device_get_sysname(device)); + VIR_DEBUG("Could not determine device type for device " + "with sysfs path '%s'", + udev_device_get_sysname(device)); ret = -1; out: @@ -1209,8 +1209,8 @@ static int udevRemoveOneDevice(struct udev_device *device) dev->def->name, name); virNodeDeviceObjRemove(&driverState->devs, dev); } else { - VIR_INFO("Failed to find device to remove that has udev name '%s'", - name); + VIR_DEBUG("Failed to find device to remove that has udev name '%s'", + name); ret = -1; } nodeDeviceUnlock(driverState); @@ -1237,8 +1237,8 @@ static int udevSetParent(struct udev_device *device, parent_sysfs_path = udev_device_get_syspath(parent_device); if (parent_sysfs_path == NULL) { - VIR_INFO("Could not get syspath for parent of '%s'", - udev_device_get_syspath(parent_device)); + VIR_DEBUG("Could not get syspath for parent of '%s'", + udev_device_get_syspath(parent_device)); } dev = virNodeDeviceFindBySysfsPath(&driverState->devs, @@ -1350,8 +1350,8 @@ static int udevProcessDeviceListEntry(struct udev *udev, if (device != NULL) { if (udevAddOneDevice(device) != 0) { - VIR_INFO("Failed to create node device for udev device '%s'", - name); + VIR_DEBUG("Failed to create node device for udev device '%s'", + name); } ret = 0; } @@ -1598,8 +1598,8 @@ static int udevDeviceMonitorStartup(int privileged ATTRIBUTE_UNUSED) if ((pciret = pci_system_init()) != 0) { char ebuf[256]; - VIR_INFO("Failed to initialize libpciaccess: %s", - virStrerror(pciret, ebuf, sizeof ebuf)); + VIR_ERROR("Failed to initialize libpciaccess: %s", + virStrerror(pciret, ebuf, sizeof ebuf)); ret = -1; goto out; } -- 1.7.4

3 2

[libvirt] [libvirt-snmp][PATCH] Created .gitignore to ignore generated/compiled files.
by Michal Privoznik 09 Feb '11

09 Feb '11

I've forgotten to add .gitignore to let git ignore some garbage. --- .gitignore | 27 +++++++++++++++++++++++++++ src/.gitignore | 10 ++++++++++ 2 files changed, 37 insertions(+), 0 deletions(-) create mode 100644 .gitignore create mode 100644 src/.gitignore diff --git a/.gitignore b/.gitignore new file mode 100644 index 0000000..f4821fb --- /dev/null +++ b/.gitignore @@ -0,0 +1,27 @@ +#*# +*.#*# +*.a +*.exe +*.gcda +*.gcno +*.gcov +*.o +*.orig +*.rej +*~ +.git +.git-module-status +/Makefile +/Makefile.in +/aclocal.m4 +/autom4te.cache/ +/config.h +/config.h.in +/config.log +/config.status +/configure +/depcomp +/install-sh +/libvirt-snmp.spec +/missing +/stamp-h1 diff --git a/src/.gitignore b/src/.gitignore new file mode 100644 index 0000000..2c8801e --- /dev/null +++ b/src/.gitignore @@ -0,0 +1,10 @@ +Makefile +Makefile.in +.deps +.libs +*.lo +*.loT +*.la +*.exe +*.cov +/libvirtMib_subagent -- 1.7.3.5

2 1

[libvirt] [PATCH] Reserve PCI addresses 3 and 4 on qemu-system-ppc
by Niels de Vos 09 Feb '11

09 Feb '11

On PPC emulated by recent versions of qemu, PCI-bus 0 already has a macio connected in slot 3 and OHCI on slot 4. Reference: - https://bugzilla.redhat.com/show_bug.cgi?id=667345 Signed-off-by: Niels de Vos <ndevos(a)redhat.com> --- Imho this patch is relatively ugly. Unfortunately I did not find a better way of changing the reserved PCI-addresses on a per architecture basis. It can well be that qemuAssignDevicePCISlots() needs to be updated for other architectures as well. A more modular/dynamic approach might be more suitable. Feel free to suggest an alternative way to solve this. Thanks, Niels src/qemu/qemu_command.c | 8 ++++++++ 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c index f78ce71..50e3ad7 100644 --- a/src/qemu/qemu_command.c +++ b/src/qemu/qemu_command.c @@ -983,6 +983,14 @@ qemuAssignDevicePCISlots(virDomainDefPtr def, qemuDomainPCIAddressSetPtr addrs) goto error; } + /* qemu-system-ppc has macio on slot 3 and ohci on slot 4 */ + if (STREQ(def->os.arch, "ppc")) { + if (qemuDomainPCIAddressReserveSlot(addrs, 3) < 0) + goto error; + if (qemuDomainPCIAddressReserveSlot(addrs, 4) < 0) + goto error; + } + /* Network interfaces */ for (i = 0; i < def->nnets ; i++) { if (def->nets[i]->info.type != VIR_DOMAIN_DEVICE_ADDRESS_TYPE_NONE) -- 1.7.4

3 4

[libvirt] [PATCH RFC] Don't use CLONE_NEWUSER for now
by Serge E. Hallyn 09 Feb '11

09 Feb '11

Until now, user namespaces have not done much, but (for that reason) have been innocuous to glob in with other CLONE_ flags. Upcoming userns development, however, will make tasks cloned with CLONE_NEWUSER far more restricted. In particular, for some time they will be unable to access files with anything other than the world access perms. This patch assumes that noone really needs the user namespaces to be enabled. If that is wrong, then we can try a more baroque patch where we create a file owned by a test userid with 700 perms and, if we can't access it after setuid'ing to that userid, then return 0. Otherwise, assume we are using an older, 'harmless' user namespace implementation. Comments appreciated. Is it ok to do this? Signed-off-by: Serge Hallyn <serge.hallyn(a)canonical.com> --- src/lxc/lxc_container.c | 7 +++++++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/src/lxc/lxc_container.c b/src/lxc/lxc_container.c index 876bc62..a735eb7 100644 --- a/src/lxc/lxc_container.c +++ b/src/lxc/lxc_container.c @@ -810,7 +810,14 @@ static int lxcContainerChild( void *data ) static int userns_supported(void) { +#if 1 + /* + * put off using userns until uid mapping is implemented + */ + return 0; +#else return lxcContainerAvailable(LXC_CONTAINER_FEATURE_USER) == 0; +#endif } /** -- 1.7.2.3

3 2

[libvirt] [PATCH v2] storage: Allow to delete device mapper disk partition
by Osier Yang 09 Feb '11

09 Feb '11

The name convention of device mapper disk is different, and 'parted' can't be used to delete a device mapper disk partition. e.g. # virsh vol-list --pool osier Name Path ----------------------------------------- 3600a0b80005ad1d7000093604cae912fp1 /dev/mapper/3600a0b80005ad1d7000093604cae912fp1 # parted /dev/mapper/3600a0b80005adb0b0000ab2d4cae9254 rm p1 Error: Expecting a partition number. This patch introduces 'dmsetup' to fix it. Changes: - New function "virIsDevMapperDevice" in "src/utils/utils.c" - remove "is_dm_device" in "src/storage/parthelper.c", use "virIsDevMapperDevice" instead. - Requires "device-mapper" for 'with-storage-disk" in "libvirt.spec.in" - Check "dmsetup" in 'configure.ac' for "with-storage-disk" - Changes on "src/Makefile.am" to link against libdevmapper - New entry for "virIsDevMapperDevice" in "src/libvirt_private.syms" Changes from v1 to v2: - s/virIsDeviceMapperDevice/virIsDevMapperDevice/g - replace "virRun" with "virCommand" - sort the list of util functions in "libvirt_private.syms" e.g. # virsh vol-list --pool osier Name Path ----------------------------------------- 3600a0b80005ad1d7000093604cae912fp1 /dev/mapper/3600a0b80005ad1d7000093604cae912fp1 # virsh vol-delete /dev/mapper/3600a0b80005ad1d7000093604cae912fp1 Vol /dev/mapper/3600a0b80005ad1d7000093604cae912fp1 deleted # virsh vol-list --pool osier Name Path ----------------------------------------- --- configure.ac | 19 ++++++++++++++ libvirt.spec.in | 1 + src/Makefile.am | 8 +++--- src/libvirt_private.syms | 5 ++- src/storage/parthelper.c | 14 +--------- src/storage/storage_backend_disk.c | 48 +++++++++++++++++++++-------------- src/util/util.c | 14 ++++++++++ src/util/util.h | 2 + 8 files changed, 73 insertions(+), 38 deletions(-) diff --git a/configure.ac b/configure.ac index 8a4083f..9517bfc 100644 --- a/configure.ac +++ b/configure.ac @@ -1706,12 +1706,19 @@ LIBPARTED_LIBS= if test "$with_storage_disk" = "yes" || test "$with_storage_disk" = "check"; then AC_PATH_PROG([PARTED], [parted], [], [$PATH:/sbin:/usr/sbin]) + AC_PATH_PROG([DMSETUP], [dmsetup], [], [$PATH:/sbin:/usr/sbin]) if test -z "$PARTED" ; then PARTED_FOUND=no else PARTED_FOUND=yes fi + if test -z "$DMSETUP" ; then + DMSETUP_FOUND=no + else + DMSETUP_FOUND=yes + fi + if test "$PARTED_FOUND" = "yes" && test "x$PKG_CONFIG" != "x" ; then PKG_CHECK_MODULES([LIBPARTED], [libparted >= $PARTED_REQUIRED], [], [PARTED_FOUND=no]) @@ -1739,11 +1746,23 @@ if test "$with_storage_disk" = "yes" || with_storage_disk=yes fi + if test "$DMSETUP_FOUND" = "no" ; then + if test "$with_storage_disk" = "yes" ; then + AC_MSG_ERROR([We need dmsetup for disk storage driver]) + else + with_storage_disk=no + fi + else + with_storage_disk=yes + fi + if test "$with_storage_disk" = "yes"; then AC_DEFINE_UNQUOTED([WITH_STORAGE_DISK], 1, [whether Disk backend for storage driver is enabled]) AC_DEFINE_UNQUOTED([PARTED],["$PARTED"], [Location or name of the parted program]) + AC_DEFINE_UNQUOTED([DMSETUP],["$DMSETUP"], + [Location or name of the dmsetup program]) fi fi AM_CONDITIONAL([WITH_STORAGE_DISK], [test "$with_storage_disk" = "yes"]) diff --git a/libvirt.spec.in b/libvirt.spec.in index 0a2d10e..27e6a99 100644 --- a/libvirt.spec.in +++ b/libvirt.spec.in @@ -279,6 +279,7 @@ Requires: iscsi-initiator-utils %if %{with_storage_disk} # For disk driver Requires: parted +Requires: device-mapper %endif %if %{with_storage_mpath} # For multipath support diff --git a/src/Makefile.am b/src/Makefile.am index f8b8434..a8848bb 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -437,9 +437,9 @@ libvirt_la_BUILT_LIBADD = libvirt_util.la libvirt_util_la_SOURCES = \ $(UTIL_SOURCES) libvirt_util_la_CFLAGS = $(CAPNG_CFLAGS) $(YAJL_CFLAGS) $(LIBNL_CFLAGS) \ - $(AM_CFLAGS) $(AUDIT_CFLAGS) + $(AM_CFLAGS) $(AUDIT_CFLAGS) $(DEVMAPPER_CFLAGS) libvirt_util_la_LIBADD = $(CAPNG_LIBS) $(YAJL_LIBS) $(LIBNL_LIBS) \ - $(LIB_PTHREAD) $(AUDIT_LIBS) + $(LIB_PTHREAD) $(AUDIT_LIBS) $(DEVMAPPER_LIBS) noinst_LTLIBRARIES += libvirt_conf.la @@ -1154,7 +1154,6 @@ libvirt_parthelper_SOURCES = $(STORAGE_HELPER_DISK_SOURCES) libvirt_parthelper_LDFLAGS = $(WARN_LDFLAGS) $(AM_LDFLAGS) libvirt_parthelper_LDADD = \ $(LIBPARTED_LIBS) \ - $(DEVMAPPER_LIBS) \ libvirt_util.la \ ../gnulib/lib/libgnu.la @@ -1179,7 +1178,8 @@ libvirt_lxc_SOURCES = \ libvirt_lxc_LDFLAGS = $(WARN_CFLAGS) $(AM_LDFLAGS) libvirt_lxc_LDADD = $(CAPNG_LIBS) $(YAJL_LIBS) \ $(LIBXML_LIBS) $(NUMACTL_LIBS) $(LIB_PTHREAD) \ - $(LIBNL_LIBS) $(AUDIT_LIBS) ../gnulib/lib/libgnu.la + $(LIBNL_LIBS) $(AUDIT_LIBS) $(DEVMAPPER_LIBS) \ + ../gnulib/lib/libgnu.la libvirt_lxc_CFLAGS = \ $(LIBPARTED_CFLAGS) \ $(NUMACTL_CFLAGS) \ diff --git a/src/libvirt_private.syms b/src/libvirt_private.syms index 88e270c..63bd721 100644 --- a/src/libvirt_private.syms +++ b/src/libvirt_private.syms @@ -881,6 +881,7 @@ virGetUserID; virGetUserName; virHexToBin; virIndexToDiskName; +virIsDevMapperDevice; virKillProcess; virMacAddrCompare; virParseMacAddr; @@ -895,6 +896,8 @@ virSetCloseExec; virSetNonBlock; virSetUIDGID; virSkipSpaces; +virStrcpy; +virStrncpy; virStrToDouble; virStrToLong_i; virStrToLong_l; @@ -902,8 +905,6 @@ virStrToLong_ll; virStrToLong_ui; virStrToLong_ul; virStrToLong_ull; -virStrcpy; -virStrncpy; virTimestamp; virVasprintf; diff --git a/src/storage/parthelper.c b/src/storage/parthelper.c index 6ef413d..acc9171 100644 --- a/src/storage/parthelper.c +++ b/src/storage/parthelper.c @@ -59,18 +59,6 @@ enum diskCommand { DISK_GEOMETRY }; -static int -is_dm_device(const char *devname) -{ - struct stat buf; - - if (devname && !stat(devname, &buf) && dm_is_dm_major(major(buf.st_rdev))) { - return 1; - } - - return 0; -} - int main(int argc, char **argv) { PedDevice *dev; @@ -96,7 +84,7 @@ int main(int argc, char **argv) } path = argv[1]; - if (is_dm_device(path)) { + if (virIsDevMapperDevice(path)) { partsep = "p"; canonical_path = strdup(path); if (canonical_path == NULL) { diff --git a/src/storage/storage_backend_disk.c b/src/storage/storage_backend_disk.c index c7ade6b..05eb8c3 100644 --- a/src/storage/storage_backend_disk.c +++ b/src/storage/storage_backend_disk.c @@ -31,6 +31,7 @@ #include "storage_backend_disk.h" #include "util.h" #include "memory.h" +#include "command.h" #include "configmake.h" #define VIR_FROM_THIS VIR_FROM_STORAGE @@ -647,6 +648,7 @@ virStorageBackendDiskDeleteVol(virConnectPtr conn ATTRIBUTE_UNUSED, char *part_num = NULL; char *devpath = NULL; char *devname, *srcname; + virCommandPtr cmd = NULL; int rc = -1; if (virFileResolveLink(vol->target.path, &devpath) < 0) { @@ -660,38 +662,46 @@ virStorageBackendDiskDeleteVol(virConnectPtr conn ATTRIBUTE_UNUSED, srcname = basename(pool->def->source.devices[0].path); DEBUG("devname=%s, srcname=%s", devname, srcname); - if (!STRPREFIX(devname, srcname)) { + if (!virIsDevMapperDevice(devpath) && !STRPREFIX(devname, srcname)) { virStorageReportError(VIR_ERR_INTERNAL_ERROR, _("Volume path '%s' did not start with parent " "pool source device name."), devname); goto cleanup; } - part_num = devname + strlen(srcname); + if (!virIsDevMapperDevice(devpath)) { + part_num = devname + strlen(srcname); - if (*part_num == 0) { - virStorageReportError(VIR_ERR_INTERNAL_ERROR, - _("cannot parse partition number from target " - "'%s'"), devname); - goto cleanup; - } + if (*part_num == 0) { + virStorageReportError(VIR_ERR_INTERNAL_ERROR, + _("cannot parse partition number from target " + "'%s'"), devname); + goto cleanup; + } - /* eg parted /dev/sda rm 2 */ - const char *prog[] = { - PARTED, - pool->def->source.devices[0].path, - "rm", - "--script", - part_num, - NULL, - }; + cmd = virCommandNew(PARTED); + virCommandAddArgList(cmd, + pool->def->source.devices[0].path, + "rm", + "--script", + part_num, + NULL); - if (virRun(prog, NULL) < 0) - goto cleanup; + if (virCommandRun(cmd, NULL) < 0) + goto cleanup; + } else { + cmd = virCommandNew(DMSETUP); + virCommandAddArgList(cmd, "remove", "--force", devpath, NULL); + + if (virCommandRun(cmd, NULL) < 0) + goto cleanup; + } rc = 0; + cleanup: VIR_FREE(devpath); + virCommandFree(cmd); return rc; } diff --git a/src/util/util.c b/src/util/util.c index ee04ca9..fc2e0c9 100644 --- a/src/util/util.c +++ b/src/util/util.c @@ -45,6 +45,7 @@ #include <string.h> #include <signal.h> #include <termios.h> +#include <libdevmapper.h> #include "c-ctype.h" #ifdef HAVE_PATHS_H @@ -3100,3 +3101,16 @@ virTimestamp(void) return timestamp; } + +bool +virIsDevMapperDevice(const char *devname) +{ + struct stat buf; + + if (devname && + !stat(devname, &buf) && + dm_is_dm_major(major(buf.st_rdev))) + return true; + + return false; +} diff --git a/src/util/util.h b/src/util/util.h index 8373038..280f86e 100644 --- a/src/util/util.h +++ b/src/util/util.h @@ -296,4 +296,6 @@ int virBuildPathInternal(char **path, ...) ATTRIBUTE_SENTINEL; char *virTimestamp(void); +bool virIsDevMapperDevice(const char *devname); + #endif /* __VIR_UTIL_H__ */ -- 1.7.3.2

2 5

[libvirt] [libvirt-php 0/2] Introduce set_error() function and fix compilation warnings
by Michal Novotny 09 Feb '11

09 Feb '11

Hi, this is the patch to introduce set_error() function to be able to set error from everywhere we want (and not just using the libvirt error handler), e.g. when the API function is not available in the libvirt version the user is using. Also, the formatting and error handling has been fixed. Second part of the patch is fixing the compilation warnings. Patch has been tested on Fedora 14 box using php 5.3.4-1 version of Fedora 14 and it was working as designed. Michal Signed-off-by: Michal Novotny <minovotn(a)redhat.com> Michal Novotny (2): Introduce set_error() function and fix error handling/formatting Fix compilation warnings libvirt.c | 382 ++++++++++++++++++++++++++++++++------------------------- php_libvirt.h | 4 - 2 files changed, 212 insertions(+), 174 deletions(-) -- 1.7.3.2

2 4

[libvirt] Strange nodedev-dumpxml ??
by arnaud.champion＠devatom.fr 09 Feb '11

09 Feb '11

?Hi, I have maybe a strange thing on a nodedev-dumpxml virsh result : virsh # nodedev-dumpxml block_sr0 <device> <name>block_sr0</name> <parent>scsi_0_0_1_0</parent> <capability type='storage'> <block>/dev/sr0</block> <bus>scsi</bus> <drive_type>cdrom</drive_type> <model>DVD RW DRU-190S</model> <vendor>SONY</vendor> <capability type='removable'> <media_available>0</media_available> <media_size>0</media_size> </capability> </capability> </device> I think (note I'm not sure), the capabilty type removable should be in the device element, like this : virsh # nodedev-dumpxml block_sr0 <device> <name>block_sr0</name> <parent>scsi_0_0_1_0</parent> <capability type='storage'> <block>/dev/sr0</block> <bus>scsi</bus> <drive_type>cdrom</drive_type> <model>DVD RW DRU-190S</model> <vendor>SONY</vendor> </capability> <capability type='removable'> <media_available>0</media_available> <media_size>0</media_size> </capability> </device> Let me know if I'm wrong.

2 1

[libvirt] [PATCH] docs: Clarify usage of vram and heads
by Osier Yang 09 Feb '11

09 Feb '11

Though attributes "vram" and "heads" of "video" element are generic, they are only useful for vbox driver currently. * docs/formatdomain.html.in --- docs/formatdomain.html.in | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in index 43c78fc..c130460 100644 --- a/docs/formatdomain.html.in +++ b/docs/formatdomain.html.in @@ -1572,6 +1572,8 @@ qemu-kvm -net nic,model=? /dev/null "xen" or "vbox", depending on the hypervisor features available. You can also provide the amount of video memory in kilobytes using <code>vram</code> and the number of screen with <code>heads</code>. + NB, though <code>vram</code> and <code>heads</code> are generic + attributes, they are only useful for vbox driver. </dd> <dt><code>acceleration</code></dt> -- 1.7.3.2

3 4

[libvirt] [PATCH libvirt-site] Add libvirt-php information page
by Michal Novotny 09 Feb '11

09 Feb '11

Hi, this is the patch to add libvirt-php information page with some basic information on libvirt-php project compilation, contribution and other useful information. Michal Signed-off-by: Michal Novotny <minovotn(a)redhat.com> --- docs/bindings.html.in | 13 ++++--- docs/php.html.in | 85 +++++++++++++++++++++++++++++++++++++++++++++++++ docs/sitemap.html.in | 4 ++ 3 files changed, 96 insertions(+), 6 deletions(-) create mode 100644 docs/php.html.in diff --git a/docs/bindings.html.in b/docs/bindings.html.in index 41114f0..87d894d 100644 --- a/docs/bindings.html.in +++ b/docs/bindings.html.in @@ -27,16 +27,17 @@ </li> <li> <p> - <strong>PHP</strong>: Radek Hladik develops - <a href="http://phplibvirt.cybersales.cz/">PHP bindings</a>. + <strong>PHP</strong>: Radek Hladik started developing + <a href="http://phplibvirt.cybersales.cz/">PHP bindings</a> in 2010. </p> <p> - The php-libvirt bindings also have their source online - <a href="http://github.com/Kedarius/php-libvirt">here in Github</a>. + In February 2011 the binding development has been moved to the + <a href="http://libvirt.org/git/?p=libvirt-php.git;a=summary">libvirt.org as libvirt-php project</a>. </p> <p> - This allows you to easily see the code, make comments on it, - create your own forks, and contribute the changes back. + The project is now maintained by Michal Novotny and it's heavily based + on Radek's version. For more information including the information on posting + the patches you to libvirt-php please refer to <a href="php.html">PHP binding page</a>. </p> </li> <li> diff --git a/docs/php.html.in b/docs/php.html.in new file mode 100644 index 0000000..ea4f76a --- /dev/null +++ b/docs/php.html.in @@ -0,0 +1,85 @@ +<?xml version="1.0"?> +<html> + <body> + <h1>PHP API bindings</h1> + +<h2>Presentation</h2> + <p>The libvirt-php, originally called php-libvirt, is the PHP API bindings for + the libvirt virtualization toolkit originally developed by Radek Hladik but + currently maintained by Red Hat.</p> + +<h2>Getting the source</h2> +<p> The PHP bindings code source is now maintained in a <a +href="http://git-scm.com/">git</a> repository available on +<a href="http://libvirt.org/git/">libvirt.org</a>: +</p> +<pre> +git clone git://libvirt.org/libvirt-php.git +</pre> +<p> +It can also be browsed at +</p> +<pre> +<a href="http://libvirt.org/git/?p=libvirt-php.git;a=summary">http://libvirt.org/git/?p=libvirt-php.git;a=summary</a> +</pre> + +<p></p> +<h2>Building</h2> +<p>The code is using autotools to generate the files necessary for compilation. The preferred way of building is + to run autogen.sh to generate configure script and then go on with the standard linux make commands, i.e.</p> + +<pre> +$ cd libvirt-php +$ ./autogen.sh +$ make +</pre> + + +<h2>Enabling the module in PHP</h2> +<p>Before you start using the module you have to install the module first. The module +php_libvirt.so is being generated when you compile it. This is necessary to be loaded +in the extensions sections of php.ini file for PHP version older than PHP-5.</p> +<p> +Starting with PHP-5 you can create a file called libvirt.ini in /etc/php.d having just +one line <code>extension=php_libvirt.so</code> to enable the extension. Of course, you +need to have this module copied in the directory with the rest of your PHP modules to +make PHP find the module for you.</p> +<p> +If you're using PHP as a module (mod_php5.so) in the Apache webserver you need to +restart your Apache to trigger configuration reload for PHP. +</p> +<p> +If you're not sure that you have everything set up right and you don't want to restart +your Apache webserver before you're sure everything will be working fine you could try +running the test using cli-based PHP interpreter. There are some example scripts coming +along the source codes in the <code>example</code> subdirectory so you can try to run +php on the index.php script to check whether it's working fine to establish connection or not. +</p> +<p> +When you're having some issues with the connection make sure the apache user is having +access to libvirt. For more information please see <a href="auth.html">Libvirt access control</a> page. +</p> +<h2>Contribution</h2> +<p> +If you would like to contribute to the libvirt-php project you could write patches for it but please +make sure you're following the procedure below: + +<ol> + <li>Sign up to libvirt list if you're not on it yet (libvir-list(a)redhat.com)</li> + <li>Clone the repository from libvirt.org site using: + <pre>git clone git://libvirt.org/libvirt-php</pre> + </li> + <li>Set your git username and e-mail and also set the subject prefix in the project's repository using: + <pre>git config --local format.subjectprefix "libvirt-php"</pre> + </li> + <li>Create the patch in the form of the commits and include also information about usage (example source codes maybe) and testing</li> + <li>Format it using <code>git format-patch -X</code> where X is the number of patch parts to be posted, for multipart patch (X is greater than 1) please use also numbering (-n) option and include the cover-letter (--cover-letter).</li> + <li>Send to libvir-list(a)redhat.com using the <code>git send-email <files> --to libvir-list(a)redhat.com</code> command where <files> can be <i>000*</i> to send all the patches formatted by git format-patch since git format-patch names the files starting with the 4 digit numbers.</li> +</ol> + +When you send the patch you're patch will be reviewed and later committed to the libvirt-php repository. You'll be contacted in case some flaws are found during the review. + +</p> + + </body> +</html> diff --git a/docs/sitemap.html.in b/docs/sitemap.html.in index c987c49..ac0af71 100644 --- a/docs/sitemap.html.in +++ b/docs/sitemap.html.in @@ -266,6 +266,10 @@ <a href="csharp.html">C#</a> <span>overview of the C# API bindings</span> </li> + <li> + <a href="php.html">PHP</a> + <span>overview of the PHP API bindings</span> + </li> </ul> </li> <li> -- 1.7.3.2

2 2

[libvirt] [PATCH 0/6] sysinfo: expose host <sysinfo> data from virsh
by Eric Blake 09 Feb '11

09 Feb '11

First requested here: https://www.redhat.com/archives/libvir-list/2011-January/msg00889.html and useful enough that I coded it in one day, hopefully to be in time for the 0.8.8 feature freeze :) Food for thought - right now, only qemu supports this. Should I do a followup patch that moves hostsysinfo out of qemu_conf.h and into src/datatypes.h virConnect instead, as well as some utility routines that make it easier for all hypervisors to choose to cache sysinfo data (if privileged)? Compare to how many (but not all) hypervisors share util.c virGetHostname rather than duplicating the work. Eric Blake (6): sysinfo: expose new API sysinfo: define internal driver API sysinfo: implement the public API sysinfo: implement the remote protocol sysinfo: implement virsh support sysinfo: implement qemu support daemon/remote.c | 25 +++++++- daemon/remote_dispatch_args.h | 1 + daemon/remote_dispatch_prototypes.h | 8 ++ daemon/remote_dispatch_ret.h | 1 + daemon/remote_dispatch_table.h | 5 ++ docs/formatdomain.html.in | 4 +- include/libvirt/libvirt.h.in | 4 +- src/conf/domain_conf.c | 71 +------------------- src/driver.h | 4 + src/esx/esx_driver.c | 3 +- src/libvirt.c | 42 +++++++++++- src/libvirt_private.syms | 1 + src/libvirt_public.syms | 5 ++ src/lxc/lxc_driver.c | 1 + src/opennebula/one_driver.c | 3 +- src/openvz/openvz_driver.c | 3 +- src/phyp/phyp_driver.c | 3 +- src/qemu/qemu_driver.c | 17 +++++ src/remote/remote_driver.c | 28 ++++++++- src/remote/remote_protocol.c | 18 +++++ src/remote/remote_protocol.h | 15 ++++ src/remote/remote_protocol.x | 13 +++- src/remote_protocol-structs | 6 ++ src/test/test_driver.c | 3 +- src/uml/uml_driver.c | 1 + src/util/sysinfo.c | 125 ++++++++++++++++++++++++++++++++++- src/util/sysinfo.h | 5 +- src/vbox/vbox_tmpl.c | 1 + src/vmware/vmware_driver.c | 5 +- src/xen/xen_driver.c | 1 + src/xenapi/xenapi_driver.c | 2 + tools/virsh.c | 33 +++++++++- tools/virsh.pod | 5 ++ 33 files changed, 377 insertions(+), 85 deletions(-) -- 1.7.4

2 11

[libvirt] [PATCH] xen: Prevent updating device when attaching a device
by Osier Yang 09 Feb '11

09 Feb '11

When attaching a device that already exists, xend driver updates the device with "device_configure", it causes problems (e.g. for disk device, 'device_configure' only can be used to update device like CDROM), on the other hand, we provide additional API (virDomainUpdateDevice) to update device, this fix is to raise up errors instead of updating the existed device. * src/xen/xend_internal.c --- src/xen/xend_internal.c | 34 +++++++++++++++++++++++++++++----- 1 files changed, 29 insertions(+), 5 deletions(-) diff --git a/src/xen/xend_internal.c b/src/xen/xend_internal.c index cd30336..76c7d64 100644 --- a/src/xen/xend_internal.c +++ b/src/xen/xend_internal.c @@ -3965,6 +3965,7 @@ xenDaemonAttachDeviceFlags(virDomainPtr domain, const char *xml, virDomainDefPtr def = NULL; virBuffer buf = VIR_BUFFER_INITIALIZER; char class[8], ref[80]; + char *target = NULL; if ((domain == NULL) || (domain->conn == NULL) || (domain->name == NULL)) { virXendError(VIR_ERR_INVALID_ARG, __FUNCTION__); @@ -4029,6 +4030,11 @@ xenDaemonAttachDeviceFlags(virDomainPtr domain, const char *xml, STREQ(def->os.type, "hvm") ? 1 : 0, priv->xendConfigVersion, 1) < 0) goto cleanup; + + if (!(target = strdup(dev->data.disk->dst))) { + virReportOOMError(); + goto cleanup; + } break; case VIR_DOMAIN_DEVICE_NET: @@ -4038,6 +4044,14 @@ xenDaemonAttachDeviceFlags(virDomainPtr domain, const char *xml, STREQ(def->os.type, "hvm") ? 1 : 0, priv->xendConfigVersion, 1) < 0) goto cleanup; + + char macStr[VIR_MAC_STRING_BUFLEN]; + virFormatMacAddr(dev->data.net->mac, macStr); + + if (!(target = strdup(macStr))) { + virReportOOMError(); + goto cleanup; + } break; case VIR_DOMAIN_DEVICE_HOSTDEV: @@ -4046,6 +4060,17 @@ xenDaemonAttachDeviceFlags(virDomainPtr domain, const char *xml, if (xenDaemonFormatSxprOnePCI(dev->data.hostdev, &buf, 0) < 0) goto cleanup; + + virDomainDevicePCIAddress PCIAddr; + + PCIAddr = dev->data.hostdev->source.subsys.u.pci; + virAsprintf(&target, "PCI device: %.4x:%.2x:%.2x", PCIAddr.domain, + PCIAddr.bus, PCIAddr.slot); + + if (target == NULL) { + virReportOOMError(); + goto cleanup; + } } else { virXendError(VIR_ERR_NO_SUPPORT, "%s", _("unsupported device type")); @@ -4065,17 +4090,16 @@ xenDaemonAttachDeviceFlags(virDomainPtr domain, const char *xml, /* device doesn't exist, define it */ ret = xend_op(domain->conn, domain->name, "op", "device_create", "config", sexpr, NULL); - } - else { - /* device exists, attempt to modify it */ - ret = xend_op(domain->conn, domain->name, "op", "device_configure", - "config", sexpr, "dev", ref, NULL); + } else { + virXendError(VIR_ERR_OPERATION_INVALID, + _("target '%s' already exists"), target); } cleanup: VIR_FREE(sexpr); virDomainDefFree(def); virDomainDeviceDefFree(dev); + VIR_FREE(target); return ret; } -- 1.7.3.2

2 2

[libvirt] configuring network interface
by Marcela Castro León 08 Feb '11

08 Feb '11

Hello > > I've a lan of virtual machine configured with bridge. I've a private lan of 4 machine, but one of them have 2 lan-card with access to internet. Evertything works almost fine, except that I've configured on each guest the static configuration of the bridge with the ip address, like this: auto lo iface lo inet loopback auto eth6 iface eth6 inet static address 192.168.1.41 network 192.168.1.0 netmask 255.255.255.0 gateway 192.168.1.10 But each time I, for example, define the guest, it start with a ascending number of interface: eth6,eth7, eth8, etc, Now is initializing with eth12. So, it doesn't get the manual configuration I've done on the /etc/network/interfaces. How can avoid this way of work of the number of ethernet interface the guest start? A way i'm trying to solve is configuring the interface trough the guest xml definition, but the operation "define" on virsh accepted without error the xml i've done, but the dumpxml doesn't show them, so, it doesn't work at all. I've followed the instruction that said the manual "Application development guide - a guide to application development with libvirt" on page 71. The whole definition of the VM is attached, but the related to interface is: <interface type='bridge'> <source bridge='br0'/> <target dev='vnet0'/> <protocol> <ip address="192.168.1.41" prefix="24"/> <route gateway="192.168.1.10"/> </protocol> <bridge stp="off" delay="0.01"> <interface type="ethernet" name="eth12"> <protocol> <ip address="192.168.1.41" prefix="24"/> <route gateway="192.168.1.10"/> </protocol> </interface> </bridge> </interface> But after define, the dumpxml only show this part: <interface type='bridge'> <mac address='52:54:00:3c:92:9a'/> <source bridge='br0'/> </interface> I would appreciate any help to solve the question. The problem I've is I lost the access to the guest every time the libvirt change the name of the interface eth1,2,3, etc. Thank you very much. Marcela

2 1

[libvirt] [libvirt-php] New project on libvirt.org and information about sending patches
by Michal Novotny 08 Feb '11

08 Feb '11

Hi, based on our yesterday conversation mainly between Radek Hladik from cybersales.cz (who was the project's original maintainer), Justin Clift and me we've decided to move the project from github to libvirt.org to be GIT hosted there. I recommend using this list for the patches to be reviewed there first. I don't know whether we have to establish ACK procedure there or not however posting the patches to this list may be good mainly for brief reviews and option to explicitly NACK the patch if somebody doesn't really like the patch (and have the good reason to don't like it, of course :) ). The procedure for sending patches to libvirt-php (or php-libvirt, as the original name was - I guess both names are acceptable) is recommended to be following: 1. Sign up to libvirt list if you're not on it yet (libvir-list(a)redhat.com) 2. Clone the repository from libvirt.org site using: git clone git://libvirt.org/libvirt-php 3. Set your git username and e-mail and also set the subject prefix in the project's repository using: git config --local format.subjectprefix "libvirt-php" 4. Create the patch in the form of the commits and include also information about usage (example source codes maybe) and testing 5. Format it using `git format-patch -X` where X is the number of patch parts to be posted, for multipart patch (X > 1) please use also numbering (-n) option and include the cover-letter (--cover-letter). 6. Send to libvir-list(a)redhat.com using the `git send-email <files> --to libvir-list(a)redhat.com` command where <files> can be "000*" to send all the patches formatted by git format-patch since git format-patch names the files starting with the 4 digit numbers. Michal -- Michal Novotny<minovotn(a)redhat.com>, RHCE Virtualization Team (xen userspace), Red Hat

2 2

[libvirt] Fwd: [PATCH libvirt-site] Add libvirt-php information page
by Michal Novotny 08 Feb '11

08 Feb '11

Hi, I can't see this in the list although I'm having it in my inbox. Maybe some issue with git-send-email or something so I'm forwarding the message to make sure it's coming to the list. Michal -------- Original Message -------- Subject: [PATCH libvirt-site] Add libvirt-php information page Date: Tue, 8 Feb 2011 13:33:44 +0100 From: Michal Novotny <minovotn(a)redhat.com> To: libvir-list(a)redhat.com CC: Michal Novotny <minovotn(a)redhat.com> Hi, this is the patch to add libvirt-php information page with some basic information on libvirt-php project compilation, contribution and other useful information. Michal Signed-off-by: Michal Novotny<minovotn(a)redhat.com> --- docs/bindings.html.in | 13 ++++--- docs/php.html.in | 85 +++++++++++++++++++++++++++++++++++++++++++++++++ docs/sitemap.html.in | 4 ++ 3 files changed, 96 insertions(+), 6 deletions(-) create mode 100644 docs/php.html.in diff --git a/docs/bindings.html.in b/docs/bindings.html.in index 41114f0..87d894d 100644 --- a/docs/bindings.html.in +++ b/docs/bindings.html.in @@ -27,16 +27,17 @@ </li> <li> <p> -<strong>PHP</strong>: Radek Hladik develops -<a href="http://phplibvirt.cybersales.cz/">PHP bindings</a>. +<strong>PHP</strong>: Radek Hladik started developing +<a href="http://phplibvirt.cybersales.cz/">PHP bindings</a> in 2010. </p> <p> - The php-libvirt bindings also have their source online -<a href="http://github.com/Kedarius/php-libvirt">here in Github</a>. + In February 2011 the binding development has been moved to the +<a href="http://libvirt.org/git/?p=libvirt-php.git;a=summary">libvirt.org as libvirt-php project</a>. </p> <p> - This allows you to easily see the code, make comments on it, - create your own forks, and contribute the changes back. + The project is now maintained by Michal Novotny and it's heavily based + on Radek's version. For more information including the information on posting + the patches you to libvirt-php please refer to<a href="php.html">PHP binding page</a>. </p> </li> <li> diff --git a/docs/php.html.in b/docs/php.html.in new file mode 100644 index 0000000..ea4f76a --- /dev/null +++ b/docs/php.html.in @@ -0,0 +1,85 @@ +<?xml version="1.0"?> +<html> +<body> +<h1>PHP API bindings</h1> + +<h2>Presentation</h2> +<p>The libvirt-php, originally called php-libvirt, is the PHP API bindings for + the libvirt virtualization toolkit originally developed by Radek Hladik but + currently maintained by Red Hat.</p> + +<h2>Getting the source</h2> +<p> The PHP bindings code source is now maintained in a<a +href="http://git-scm.com/">git</a> repository available on +<a href="http://libvirt.org/git/">libvirt.org</a>: +</p> +<pre> +git clone git://libvirt.org/libvirt-php.git +</pre> +<p> +It can also be browsed at +</p> +<pre> +<a href="http://libvirt.org/git/?p=libvirt-php.git;a=summary">http://libvirt.org/git/?p=libvirt-php.git;a=summary</a> +</pre> + +<p></p> +<h2>Building</h2> +<p>The code is using autotools to generate the files necessary for compilation. The preferred way of building is + to run autogen.sh to generate configure script and then go on with the standard linux make commands, i.e.</p> + +<pre> +$ cd libvirt-php +$ ./autogen.sh +$ make +</pre> + + +<h2>Enabling the module in PHP</h2> +<p>Before you start using the module you have to install the module first. The module +php_libvirt.so is being generated when you compile it. This is necessary to be loaded +in the extensions sections of php.ini file for PHP version older than PHP-5.</p> +<p> +Starting with PHP-5 you can create a file called libvirt.ini in /etc/php.d having just +one line<code>extension=php_libvirt.so</code> to enable the extension. Of course, you +need to have this module copied in the directory with the rest of your PHP modules to +make PHP find the module for you.</p> +<p> +If you're using PHP as a module (mod_php5.so) in the Apache webserver you need to +restart your Apache to trigger configuration reload for PHP. +</p> +<p> +If you're not sure that you have everything set up right and you don't want to restart +your Apache webserver before you're sure everything will be working fine you could try +running the test using cli-based PHP interpreter. There are some example scripts coming +along the source codes in the<code>example</code> subdirectory so you can try to run +php on the index.php script to check whether it's working fine to establish connection or not. +</p> +<p> +When you're having some issues with the connection make sure the apache user is having +access to libvirt. For more information please see<a href="auth.html">Libvirt access control</a> page. +</p> +<h2>Contribution</h2> +<p> +If you would like to contribute to the libvirt-php project you could write patches for it but please +make sure you're following the procedure below: + +<ol> +<li>Sign up to libvirt list if you're not on it yet (libvir-list(a)redhat.com)</li> +<li>Clone the repository from libvirt.org site using: +<pre>git clone git://libvirt.org/libvirt-php</pre> +</li> +<li>Set your git username and e-mail and also set the subject prefix in the project's repository using: +<pre>git config --local format.subjectprefix "libvirt-php"</pre> +</li> +<li>Create the patch in the form of the commits and include also information about usage (example source codes maybe) and testing</li> +<li>Format it using<code>git format-patch -X</code> where X is the number of patch parts to be posted, for multipart patch (X is greater than 1) please use also numbering (-n) option and include the cover-letter (--cover-letter).</li> +<li>Send to libvir-list(a)redhat.com using the<code>git send-email<files> --to libvir-list(a)redhat.com</code> command where<files> can be<i>000*</i> to send all the patches formatted by git format-patch since git format-patch names the files starting with the 4 digit numbers.</li> +</ol> + +When you send the patch you're patch will be reviewed and later committed to the libvirt-php repository. You'll be contacted in case some flaws are found during the review. + +</p> + +</body> +</html> diff --git a/docs/sitemap.html.in b/docs/sitemap.html.in index c987c49..ac0af71 100644 --- a/docs/sitemap.html.in +++ b/docs/sitemap.html.in @@ -266,6 +266,10 @@ <a href="csharp.html">C#</a> <span>overview of the C# API bindings</span> </li> +<li> +<a href="php.html">PHP</a> +<span>overview of the PHP API bindings</span> +</li> </ul> </li> <li> -- 1.7.3.2

2 2

Re: [libvirt] [Qemu-devel] [PATCH 00/16] usb-ccid (v18)
by Eric Blake 07 Feb '11

07 Feb '11

[adding libvir-list as well] On 02/07/2011 08:44 AM, Alon Levy wrote: >>> I guess I'll wait a little longer for more feedback? Should I split >>> the enum property separately? it's only used by ccid-card-emualted atm. >> >> The only non-cosmetic concern I have about your series is the enum >> property so I would strongly suggest splitting it. If you did that >> for v19, it will be pretty close to merge ready. >> > > Eric, > > How does this affect libvirt? could you assume a default set of backends > if "-device ccid-card-emulated,?" returns "backend=string" instead of > "backend=A/B" ? Hmm. At the moment, libvirt only looks for "ccid-card-emulated" in the -device ? list, and hasn't yet tried inspecting -device ccid-card-emulated,? output. In short, libvirt assumes that the presence of ccid-card-emulated implies that both modes are available (libvirt's <smartcard mode='host'/> => backend=nss-emulated; <smartcard mode='host-certificates' => backend=certificates). Is it possible for qemu to have support for one, but not both, of those modes? If that's the case, then supporting "backend=nss-emulated/certificates" in -device ccid-card-emulated,? would be handy for libvirt (for example, it would be just "backend=certificates" if nss-emulated is not available). But if it's an all-or-none approach (all backends are available if ccid-card-emulated is present), then libvirt's current code won't be impacted by changing the string to the simpler "backend=string". -- Eric Blake eblake(a)redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org

3 2

[libvirt] draft ~ l10n/i18n
by Zdenek Styblik 07 Feb '11

07 Feb '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, this is a draft of libvirt l10n/i18n translator's how-to. It is nowhere definite and it actually is meant ... It's practically summarized what we've talked about in last couple days. ~~~ DRAFT ~~~ # How-to libvirt l10n/i18n We are glad you've decided to help with localization/internationalization of libvirt. Before you do anything else, stop! Please, pay attention to following lines to save yourself from eventual pitfalls. '.po' files located in this directory are synchronized from Fedora Project[https://translate.fedoraproject.org/projects/p/libvirt/], thus it makes little sense to start translating them. Here are two ways how you can translate and contribute: ## Optimal way 1st step: Create a "Fedora Project" account: https://admin.fedoraproject.org/accounts/ (New Account, etc) 2nd step: Sign in to the libvirt transifex project https://translate.fedoraproject.org/projects/p/libvirt/ It uses the just created Fedora Project account 3rd step: "Request to be a translator" Once you've signed in with step 3, there's a button under the "Translation files" heading that says something like "Request to become a translator". Press that. This is going to take some time. 4th step: Download '.po' file '.po' file can be downloaded at https://translate.fedoraproject.org/projects/p/libvirt/ 5th step: Translate See translator's tools section. 6th step: Upload translated file !!! This point is still a mystery !!! Upload modified file via web interface. ## Alternate way If for some reason you don't want to or can't register at Fedora Project, you still can translate and contribute to libvirt. 1st step: Get '.po' file Download '.po' file from https://translate.fedoraproject.org/projects/p/libvirt/ with language you're going to translate to. Make a backup copy of it 2nd step: Translate See translator's tools section. 3rd step: Make a diff Make a % diff; of the original file and the one you've translated. eg. % diff -urN lang.po.org lang.po > lang.po.patch; Send patch file back to mailing-list and somebody from the team is going to push it at Fedora Project. Why diff? Because it's easier to validate the work you've done, solve eventual conflicts etc. However, this approach has its downsides. First is it brings more workload to libvirt team, second is '.po' file can change in the meantime, because you are not able to "lock it" while you're working at translations. ## Translator's tools * KAider KDE4 ~ seems to be dead * gtranslator ~ http://projects.gnome.org/gtranslator/ * poedit ~ http://www.poedit.net/ In case '.po' file in upstream got changed and you need to sync your current work with upstream, you can try your luck with tool written in Perl > http://www.zeratul.org/git/?p=scripts/perl/po-sync/.git;a=summary ~~~ DRAFT ~~~ Have a nice weekend, Z. - -- Zdenek Styblik Net/Linux admin OS TurnovFree.net email: stybla(a)turnovfree.net jabber: stybla(a)jabber.turnovfree.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1DFJ4ACgkQ8MreUbSH7inLvQCeOg3CXKgxkdMz8EKlgQL8hSqK F6gAoI2LbWBPL2WQir0tW2wEjm5NeSlr =/2qM -----END PGP SIGNATURE-----

2 4

[libvirt] [PATCH] docs/index.html.in: update KVM url
by Niels de Vos 07 Feb '11

07 Feb '11

Signed-off-by: Niels de Vos <ndevos(a)redhat.com> --- docs/index.html.in | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/docs/index.html.in b/docs/index.html.in index 30cc9d7..d40f652 100644 --- a/docs/index.html.in +++ b/docs/index.html.in @@ -41,7 +41,7 @@ The <a href="http://wiki.qemu.org/Index.html">QEMU</a> emulator </li> <li> - The <a href="http://kvm.qumranet.com/kvmwiki">KVM</a> Linux hypervisor + The <a href="http://www.linux-kvm.org/">KVM</a> Linux hypervisor </li> <li> The <a href="http://lxc.sourceforge.net/">LXC</a> Linux container system -- 1.7.4

3 2

[libvirt] [PATCH] Support SCSI RAID type & lower log level for unknown types
by Daniel P. Berrange 07 Feb '11

07 Feb '11

The Linux kernel headers don't have a value for SCSI type 12, but HAL source code shows this to be a 'raid'. Add workaround for this type. Lower log level for unknown types since this is not a fatal error condition. Include the device sysfs path in the log output to allow identification of which device has problems. * src/node_device/node_device_udev.c: Add SCSI RAID type --- src/node_device/node_device_udev.c | 15 ++++++++++++--- 1 files changed, 12 insertions(+), 3 deletions(-) diff --git a/src/node_device/node_device_udev.c b/src/node_device/node_device_udev.c index 2da5529..93390af 100644 --- a/src/node_device/node_device_udev.c +++ b/src/node_device/node_device_udev.c @@ -41,6 +41,10 @@ #define VIR_FROM_THIS VIR_FROM_NODEDEV +#ifndef TYPE_RAID +# define TYPE_RAID 12 +#endif + struct _udevPrivate { struct udev_monitor *udev_monitor; int watch; @@ -693,7 +697,8 @@ out: } -static int udevGetSCSIType(unsigned int type, char **typestring) +static int udevGetSCSIType(virNodeDeviceDefPtr def, + unsigned int type, char **typestring) { int ret = 0; int foundtype = 1; @@ -728,6 +733,9 @@ static int udevGetSCSIType(unsigned int type, char **typestring) case TYPE_ENCLOSURE: *typestring = strdup("enclosure"); break; + case TYPE_RAID: + *typestring = strdup("raid"); + break; case TYPE_NO_LUN: default: foundtype = 0; @@ -739,7 +747,8 @@ static int udevGetSCSIType(unsigned int type, char **typestring) ret = -1; virReportOOMError(); } else { - VIR_ERROR(_("Failed to find SCSI device type %d"), type); + VIR_DEBUG("Failed to find SCSI device type %d for %s", + type, def->sysfs_path); } } @@ -784,7 +793,7 @@ static int udevProcessSCSIDevice(struct udev_device *device ATTRIBUTE_UNUSED, switch (udevGetUintSysfsAttr(device, "type", &tmp, 0)) { case PROPERTY_FOUND: - if (udevGetSCSIType(tmp, &data->scsi.type) == -1) { + if (udevGetSCSIType(def, tmp, &data->scsi.type) == -1) { goto out; } break; -- 1.7.4

2 1

[libvirt] [PATCH] Only initialize/cleanup libpciaccess once
by Daniel P. Berrange 07 Feb '11

07 Feb '11

libpciaccess has many bugs in its pci_system_init/cleanup functions that makes calling them multiple times unwise. eg it will double close() FDs, and leak other FDs. * src/node_device/node_device_udev.c: Only initialize libpciaccess once --- src/node_device/node_device_udev.c | 25 +++++++++++++------------ 1 files changed, 13 insertions(+), 12 deletions(-) diff --git a/src/node_device/node_device_udev.c b/src/node_device/node_device_udev.c index 379af86..2da5529 100644 --- a/src/node_device/node_device_udev.c +++ b/src/node_device/node_device_udev.c @@ -363,18 +363,10 @@ static int udevTranslatePCIIds(unsigned int vendor, char **vendor_string, char **product_string) { - int ret = -1, pciret; + int ret = -1; struct pci_id_match m; const char *vendor_name = NULL, *device_name = NULL; - if ((pciret = pci_system_init()) != 0) { - char ebuf[256]; - VIR_INFO("Failed to initialize libpciaccess: %s", - virStrerror(pciret, ebuf, sizeof ebuf)); - ret = 0; - goto out; - } - m.vendor_id = vendor; m.device_id = product; m.subvendor_id = PCI_MATCH_ANY; @@ -406,9 +398,6 @@ static int udevTranslatePCIIds(unsigned int vendor, } } - /* pci_system_cleanup returns void */ - pci_system_cleanup(); - ret = 0; out: @@ -1426,6 +1415,9 @@ static int udevDeviceMonitorShutdown(void) ret = -1; } + /* pci_system_cleanup returns void */ + pci_system_cleanup(); + return ret; } @@ -1593,6 +1585,15 @@ static int udevDeviceMonitorStartup(int privileged ATTRIBUTE_UNUSED) udevPrivate *priv = NULL; struct udev *udev = NULL; int ret = 0; + int pciret; + + if ((pciret = pci_system_init()) != 0) { + char ebuf[256]; + VIR_INFO("Failed to initialize libpciaccess: %s", + virStrerror(pciret, ebuf, sizeof ebuf)); + ret = -1; + goto out; + } if (VIR_ALLOC(priv) < 0) { virReportOOMError(); -- 1.7.4

2 1

Re: [libvirt] Vietnamese Translation for libvirt
by Hero Phương 07 Feb '11

07 Feb '11

>Is it ok with you, if we ask the other translation people how >they get around this problem? :) Because I use Ubuntu and I don't use the libvirt package very often (because I like the GUI of VirtualBox more). If there's any luck that I can see a wrong translation string, I'll fix it immediately. Other than that I can't do anything else. :( 2011/2/7 Justin Clift <jclift(a)redhat.com> > On 08/02/2011, at 12:26 AM, Hero Phương wrote: > > The only and biggest problem is that I can not access all the > > feature (because of limited ability) in libvirt so I can not > > see the whole context for all string. > > Yeah, I can see how that would be a problem. > > Is it ok with you, if we ask the other translation people how > they get around this problem? :) > > Regards and best wishes, > > Justin Clift >

2 1

Re: [libvirt] Vietnamese Translation for libvirt
by Hero Phương 07 Feb '11

07 Feb '11

The only and biggest problem is that I can not access all the feature (because of limited ability) in libvirt so I can not see the whole context for all string. 2011/2/7 Justin Clift <jclift(a)redhat.com> > On 07/02/2011, at 11:36 PM, Hero Phương wrote: > > It's good to do the translation work. So if I can do anything, I will do > my best to complete it. > > Then, I am very happy to hear the instruction from you. > > Cool. :) > > The Fedora Translation team have a "Quick Start Guide" here, with > instructions > in it: > > > http://docs.fedoraproject.org/en-US/Fedora_Contributor_Documentation/1/html… > > By the way, did you mean to reply to only me, rather than the two > translation > team guys CC'd on the previous email? They would be useful for you to be > in contact with. :) > > Regards and best wishes, > > Justin Clift >

1 0

[libvirt] fork of php-libvirt
by Lyre 07 Feb '11

07 Feb '11

I've added many APIs to php-libvirt, including network, node device, interface, and snapshot support. Unfortunately, I wasn't able to contact original author Radek, I really hope he can see this. So I forked it, the address is: https://github.com/4179e1/php-libvirt But there's something undone, as a new php extension writer, I don't know how the documents are generated. Any clues are appreciated. BTW, I've pack php-libvirt into rpm via opensuse build service, currently: it's ready on openSuSE 11.3 & SLES 11 SP1; fedora 14 should works too (it works on my VM), but the obs environment is not ready yet; and there's something need to workaround on rhel6. check here: http://download.opensuse.org/repositories/home:/midmay/

5 16

[libvirt] Reminder: entering freeze for 0.8.8 Wed
by Daniel Veillard 07 Feb '11

07 Feb '11

As suggested previously we should enter the freeze phase for 0.8.8 soon to target a release around the 15th. I suggest to keep the window open 2 more days, and start the freeze on Wed 9 to have a release on the 15th or 16th, Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel(a)veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/

1 0

[libvirt] if you use user namespaces
by Serge E. Hallyn 07 Feb '11

07 Feb '11

Please let me know. lxc does not use them right now. Libvirt uses them for lxc containers f they are available, but I hope we can essentially have it stop for awhile. In addition, there's tons of software out there that I don't know about, and fear of breaking their use of current user namespaces has been keeping me from pushing further userns patches. I've outlined how I see user namespaces developing at https://wiki.ubuntu.com/UserNamespace . Note there is nothing new in there - some of it goes a year back, much of it more than two years. Nothing actually new. Currently user namespaces are not very useful, but they do provide separate uid accounting, and simply tossing CLONE_NEWUSER in with CLONE_NEWNS and friends has until now been safe to do. As you can see, that is going to change. So if that would cause you pain that you can't work around, please get back to me. Otherwise, I'd like to get serious soon about expanding upon, and pushing upstream, the patches to make CLONE_NEWUSER more useful for sandboxing. thanks, -serge

1 0

[libvirt] Live migration using virsh
by rajalakshmi 06 Feb '11

06 Feb '11

Sir, I am working in cloud environment and i have set up a private cloud using eucalyptus. I am trying to migrate virtual machines within the cloud using virsh migrate command. I could successfully implement it but when i wanted to know the method used to do live migration. I tried to interpret the code. I also saw that they are setting a flag initially if it is live migration and then assigning 1 to variable live. and i also could find that xenDomainMigratePrepare is calling xend_op which in turn is calling xend_op_ext. But i could'n understand the method of migration. Can you please explain the logic?

2 1

[libvirt] Vietnamese Translation for libvirt
by Hero Phương 06 Feb '11

06 Feb '11

Dear LibVirt team, I am Phuong, one of Ubuntu Vietnamese Translation team's members. I have translated your package into my native language. I'm going to send the .po file to launchpad and I also would like to send one to your team. I'm looking forward to hearing from all you soon. Regards, HeroP

2 1

[libvirt] [PATCHv5 6/9] spicevmc: support new qemu chardev
by Eric Blake 04 Feb '11

04 Feb '11

From: Daniel P. Berrange <berrange(a)redhat.com> Inspired by https://bugzilla.redhat.com/show_bug.cgi?id=615757 Add a new character device backend for virtio serial channels that activates the QEMU spice agent on the main channel using the vdagent spicevmc connection. The <target> must be type='virtio', and supports an optional name that specifies how the guest will see the channel (for now, name must be com.redhat.spice.0). <channel type='spicevmc'> <target type='virtio'/> <address type='virtio-serial' controller='1' bus='0' port='3'/> </channel> * docs/schemas/domain.rng: Support new XML. * docs/formatdomain.html.in: Document it. * src/conf/domain_conf.h (virDomainChrType): New enum value. * src/conf/domain_conf.c (virDomainChr): Add spicevmc. (virDomainChrDefParseXML, virDomainChrSourceDefParseXML) (virDomainChrDefParseTargetXML): Parse and enforce proper use. (virDomainChrSourceDefFormat, virDomainChrDefFormat): Format. * src/qemu/qemu_command.c (qemuBuildChrChardevStr) (qemuBuildCommandLine): Add qemu support. * tests/qemuxml2argvtest.c (domain): New test. * tests/qemuxml2argvdata/qemuxml2argv-channel-spicevmc.xml: New file. * tests/qemuxml2argvdata/qemuxml2argv-channel-spicevmc.args: Likewise. Signed-off-by: Eric Blake <eblake(a)redhat.com> --- Notes: v5: new patch, but heavily ported from RHEL 6.0 docs/formatdomain.html.in | 17 +++++++ docs/schemas/domain.rng | 3 +- src/conf/domain_conf.c | 18 +++++++- src/conf/domain_conf.h | 2 + src/qemu/qemu_command.c | 47 ++++++++++++++++--- .../qemuxml2argv-channel-spicevmc.args | 9 ++++ .../qemuxml2argv-channel-spicevmc.xml | 34 ++++++++++++++ tests/qemuxml2argvtest.c | 3 + 8 files changed, 123 insertions(+), 10 deletions(-) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-channel-spicevmc.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-channel-spicevmc.xml diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in index 9f1bb5f..d91fdb9 100644 --- a/docs/formatdomain.html.in +++ b/docs/formatdomain.html.in @@ -1734,6 +1734,9 @@ qemu-kvm -net nic,model=? /dev/null <channel type='pty'> <target type='virtio' name='arbitrary.virtio.serial.port.name'/> </channel> + <channel type='spicevmc'> + <target type='virtio' name='com.redhat.spice.0'/> + </channel> </devices> ...</pre> @@ -1759,6 +1762,20 @@ qemu-kvm -net nic,model=? /dev/null optional element <code>address</code> can tie the channel to a particular <code>type='virtio-serial'</code> controller. <span class="since">Since 0.7.7</span></dd> + + <dt><code>spicevmc</code></dt> + <dd>Paravirtualized SPICE channel. The domain must also have a + SPICE server as a <a href="#elementsGraphics">graphics + device</a>, at which point the host piggy-backs messages + across the <code>main</code> channel. The <code>target</code> + element must be present, with + attribute <code>type='virtio'</code>; an optional + attribute <code>name</code> controls how the guest will have + access to the channel, and defaults + to <code>name='com.redhat.spice.0'</code>. The + optional <code>address</code> element can tie the channel to a + particular <code>type='virtio-serial'</code> controller. + <span class="since">Since 0.8.8</span></dd> </dl> <h5><a name="elementsCharHostInterface">Host interface</a></h5> diff --git a/docs/schemas/domain.rng b/docs/schemas/domain.rng index 69fb432..9ffcf21 100644 --- a/docs/schemas/domain.rng +++ b/docs/schemas/domain.rng @@ -1475,6 +1475,7 @@ <value>stdio</value> <value>vc</value> <value>pty</value> + <value>spicevmc</value> </choice> </attribute> </define> @@ -1611,7 +1612,7 @@ <define name="virtioTarget"> <element name="target"> <attribute name="type"> - <value>virtio</value> + <value>virtio</value> </attribute> <optional> <attribute name="name"/> diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c index b1c775b..9b4ef8d 100644 --- a/src/conf/domain_conf.c +++ b/src/conf/domain_conf.c @@ -226,7 +226,8 @@ VIR_ENUM_IMPL(virDomainChr, VIR_DOMAIN_CHR_TYPE_LAST, "stdio", "udp", "tcp", - "unix") + "unix", + "spicevmc") VIR_ENUM_IMPL(virDomainChrTcpProtocol, VIR_DOMAIN_CHR_TCP_PROTOCOL_LAST, "raw", @@ -3065,6 +3066,7 @@ virDomainChrSourceDefParseXML(virDomainChrSourceDefPtr def, break; case VIR_DOMAIN_CHR_TYPE_STDIO: + case VIR_DOMAIN_CHR_TYPE_SPICEVMC: /* Nada */ break; @@ -3254,6 +3256,13 @@ virDomainChrDefParseXML(virCapsPtr caps, } } + if (def->source.type == VIR_DOMAIN_CHR_TYPE_SPICEVMC && + def->targetType != VIR_DOMAIN_CHR_CHANNEL_TARGET_TYPE_VIRTIO) { + virDomainReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", + _("spicevmc device type only supports virtio")); + goto error; + } + if (virDomainDeviceInfoParseXML(node, &def->info, flags) < 0) goto error; @@ -3361,6 +3370,12 @@ virDomainSmartcardDefParseXML(xmlNodePtr node, cur = node->children; if (virDomainChrSourceDefParseXML(&def->data.passthru, cur) < 0) goto error; + + if (def->data.passthru.type == VIR_DOMAIN_CHR_TYPE_SPICEVMC) { + virDomainReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", + _("smartcard spicevmc device not supported")); + goto error; + } break; default: @@ -6843,6 +6858,7 @@ virDomainChrSourceDefFormat(virBufferPtr buf, case VIR_DOMAIN_CHR_TYPE_NULL: case VIR_DOMAIN_CHR_TYPE_VC: case VIR_DOMAIN_CHR_TYPE_STDIO: + case VIR_DOMAIN_CHR_TYPE_SPICEVMC: /* nada */ break; diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h index 81c3f38..9dff580 100644 --- a/src/conf/domain_conf.h +++ b/src/conf/domain_conf.h @@ -413,6 +413,7 @@ enum virDomainChrType { VIR_DOMAIN_CHR_TYPE_UDP, VIR_DOMAIN_CHR_TYPE_TCP, VIR_DOMAIN_CHR_TYPE_UNIX, + VIR_DOMAIN_CHR_TYPE_SPICEVMC, VIR_DOMAIN_CHR_TYPE_LAST, }; @@ -432,6 +433,7 @@ typedef virDomainChrSourceDef *virDomainChrSourceDefPtr; struct _virDomainChrSourceDef { int type; /* virDomainChrType */ union { + /* no <source> for null, vc, stdio, spicevmc */ struct { char *path; } file; /* pty, file, pipe, or device */ diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c index 40d92f4..1903c70 100644 --- a/src/qemu/qemu_command.c +++ b/src/qemu/qemu_command.c @@ -2006,7 +2006,8 @@ qemuBuildUSBHostdevUsbDevStr(virDomainHostdevDefPtr dev) /* This function outputs a -chardev command line option which describes only the * host side of the character device */ static char * -qemuBuildChrChardevStr(virDomainChrSourceDefPtr dev, const char *alias) +qemuBuildChrChardevStr(virDomainChrSourceDefPtr dev, const char *alias, + unsigned long long qemuCmdFlags) { virBuffer buf = VIR_BUFFER_INITIALIZER; bool telnet; @@ -2072,6 +2073,21 @@ qemuBuildChrChardevStr(virDomainChrSourceDefPtr dev, const char *alias) dev->data.nix.path, dev->data.nix.listen ? ",server,nowait" : ""); break; + + case VIR_DOMAIN_CHR_TYPE_SPICEVMC: + if (!(qemuCmdFlags & QEMUD_CMD_FLAG_CHARDEV_SPICEVMC)) { + qemuReportError(VIR_ERR_CONFIG_UNSUPPORTED, + _("spicevmc not supported in this QEMU binary")); + goto error; + } + virBufferVSprintf(&buf, "spicevmc,id=char%s,name=vdagent", alias); + break; + + default: + qemuReportError(VIR_ERR_CONFIG_UNSUPPORTED, + _("unsupported chardev '%s'"), + virDomainChrTypeToString(dev->type)); + goto error; } if (virBufferError(&buf)) { @@ -2196,6 +2212,14 @@ qemuBuildVirtioSerialPortDevStr(virDomainChrDefPtr dev) virBufferVSprintf(&buf, ",chardev=char%s,id=%s", dev->info.alias, dev->info.alias); + if (dev->source.type == VIR_DOMAIN_CHR_TYPE_SPICEVMC && + dev->target.name && + STRNEQ(dev->target.name, "com.redhat.spice.0")) { + qemuReportError(VIR_ERR_CONFIG_UNSUPPORTED, + _("Unsupported spicevmc target name '%s'"), + dev->target.name); + goto error; + } if (dev->target.name) { virBufferVSprintf(&buf, ",name=%s", dev->target.name); } @@ -2825,7 +2849,8 @@ qemuBuildCommandLine(virConnectPtr conn, if (qemuCmdFlags & QEMUD_CMD_FLAG_CHARDEV) { virCommandAddArg(cmd, "-chardev"); - if (!(chrdev = qemuBuildChrChardevStr(monitor_chr, "monitor"))) + if (!(chrdev = qemuBuildChrChardevStr(monitor_chr, "monitor", + qemuCmdFlags))) goto error; virCommandAddArg(cmd, chrdev); VIR_FREE(chrdev); @@ -3523,7 +3548,8 @@ qemuBuildCommandLine(virConnectPtr conn, virCommandAddArg(cmd, "-chardev"); if (!(devstr = qemuBuildChrChardevStr(&smartcard->data.passthru, - smartcard->info.alias))) { + smartcard->info.alias, + qemuCmdFlags))) { virBufferFreeAndReset(&opt); goto error; } @@ -3560,7 +3586,8 @@ qemuBuildCommandLine(virConnectPtr conn, (qemuCmdFlags & QEMUD_CMD_FLAG_DEVICE)) { virCommandAddArg(cmd, "-chardev"); if (!(devstr = qemuBuildChrChardevStr(&serial->source, - serial->info.alias))) + serial->info.alias, + qemuCmdFlags))) goto error; virCommandAddArg(cmd, devstr); VIR_FREE(devstr); @@ -3592,7 +3619,8 @@ qemuBuildCommandLine(virConnectPtr conn, (qemuCmdFlags & QEMUD_CMD_FLAG_DEVICE)) { virCommandAddArg(cmd, "-chardev"); if (!(devstr = qemuBuildChrChardevStr(&parallel->source, - parallel->info.alias))) + parallel->info.alias, + qemuCmdFlags))) goto error; virCommandAddArg(cmd, devstr); VIR_FREE(devstr); @@ -3626,7 +3654,8 @@ qemuBuildCommandLine(virConnectPtr conn, virCommandAddArg(cmd, "-chardev"); if (!(devstr = qemuBuildChrChardevStr(&channel->source, - channel->info.alias))) + channel->info.alias, + qemuCmdFlags))) goto error; virCommandAddArg(cmd, devstr); VIR_FREE(devstr); @@ -3653,7 +3682,8 @@ qemuBuildCommandLine(virConnectPtr conn, virCommandAddArg(cmd, "-chardev"); if (!(devstr = qemuBuildChrChardevStr(&channel->source, - channel->info.alias))) + channel->info.alias, + qemuCmdFlags))) goto error; virCommandAddArg(cmd, devstr); VIR_FREE(devstr); @@ -3682,7 +3712,8 @@ qemuBuildCommandLine(virConnectPtr conn, virCommandAddArg(cmd, "-chardev"); if (!(devstr = qemuBuildChrChardevStr(&console->source, - console->info.alias))) + console->info.alias, + qemuCmdFlags))) goto error; virCommandAddArg(cmd, devstr); VIR_FREE(devstr); diff --git a/tests/qemuxml2argvdata/qemuxml2argv-channel-spicevmc.args b/tests/qemuxml2argvdata/qemuxml2argv-channel-spicevmc.args new file mode 100644 index 0000000..681f7c2 --- /dev/null +++ b/tests/qemuxml2argvdata/qemuxml2argv-channel-spicevmc.args @@ -0,0 +1,9 @@ +LC_ALL=C PATH=/bin HOME=/home/test USER=test LOGNAME=test QEMU_AUDIO_DRV=spice \ +/usr/bin/qemu -S -M pc -m 214 -smp 1 -nodefconfig -nodefaults \ +-monitor unix:/tmp/test-monitor,server,nowait -no-acpi -boot c -device \ +virtio-serial-pci,id=virtio-serial1,bus=pci.0,addr=0xa -hda \ +/dev/HostVG/QEMUGuest1 -chardev spicevmc,id=charchannel0,name=vdagent -device \ +virtserialport,bus=virtio-serial1.0,nr=3,chardev=charchannel0,id=channel0\ +,name=com.redhat.spice.0 -usb -spice port=5903,tls-port=5904,addr=127.0.0.1,\ +x509-dir=/etc/pki/libvirt-spice,tls-channel=main -device \ +virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3 diff --git a/tests/qemuxml2argvdata/qemuxml2argv-channel-spicevmc.xml b/tests/qemuxml2argvdata/qemuxml2argv-channel-spicevmc.xml new file mode 100644 index 0000000..0e82394 --- /dev/null +++ b/tests/qemuxml2argvdata/qemuxml2argv-channel-spicevmc.xml @@ -0,0 +1,34 @@ +<domain type='qemu'> + <name>QEMUGuest1</name> + <uuid>c7a5fdbd-edaf-9455-926a-d65c16db1809</uuid> + <memory>219136</memory> + <vcpu cpuset='1-4,8-20,525'>1</vcpu> + <os> + <type arch='i686' machine='pc'>hvm</type> + <boot dev='hd'/> + </os> + <clock offset='utc'/> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>destroy</on_crash> + <devices> + <emulator>/usr/bin/qemu</emulator> + <disk type='block' device='disk'> + <source dev='/dev/HostVG/QEMUGuest1'/> + <target dev='hda' bus='ide'/> + <address type='drive' controller='0' bus='0' unit='0'/> + </disk> + <controller type='ide' index='0'/> + <controller type='virtio-serial' index='1'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x0a' function='0x0'/> + </controller> + <graphics type='spice' port='5903' tlsPort='5904' autoport='no' listen='127.0.0.1'> + <channel name='main' mode='secure'/> + </graphics> + <channel type='spicevmc'> + <target type='virtio' name='com.redhat.spice.0'/> + <address type='virtio-serial' controller='1' bus='0' port='3'/> + </channel> + <memballoon model='virtio'/> + </devices> +</domain> diff --git a/tests/qemuxml2argvtest.c b/tests/qemuxml2argvtest.c index 0b4bfeb..0726130 100644 --- a/tests/qemuxml2argvtest.c +++ b/tests/qemuxml2argvtest.c @@ -407,6 +407,9 @@ mymain(int argc, char **argv) QEMUD_CMD_FLAG_NODEFCONFIG, false); DO_TEST("console-virtio", QEMUD_CMD_FLAG_DEVICE | QEMUD_CMD_FLAG_NODEFCONFIG, false); + DO_TEST("channel-spicevmc", QEMUD_CMD_FLAG_DEVICE | + QEMUD_CMD_FLAG_NODEFCONFIG | QEMUD_CMD_FLAG_SPICE | + QEMUD_CMD_FLAG_CHARDEV_SPICEVMC, false); DO_TEST("smartcard-host", QEMUD_CMD_FLAG_CHARDEV | QEMUD_CMD_FLAG_DEVICE | -- 1.7.4

3 10

[libvirt] [PATCHv5 0/9] smartcard round 5
by Eric Blake 04 Feb '11

04 Feb '11

Next round. The first 5 patches were previously ack'd in round 4: https://www.redhat.com/archives/libvir-list/2011-February/msg00026.html However, I heavily rewrote patch 3 to support later spicevmc patches, as well as tweaked patch 1 and 5 to avoid the need for memory rounding. Patch 6 is mostly a port of a patch that has already seen use in RHEL 6.0 which adds the use of -chardev spicevmc,name=vdagent as a means of communicating with the guest using messages across the main SPICE graphics channel, but tweaked to be a bit more robust. Patch 7 was an experiment to add a new vdagent channel type instead of reusing virtio for the spicevmc channel; I think it failed, but wanted to at least post it in case I was on the right track after all. Patch 8 undoes 7. It won't hurt my feelings if you skip those. Patch 9 therefore immediately follows patch 6, and marries the two concepts to create a smartcard passthrough device that uses a new smartcard channel of the SPICE server. Again, this entire series depends on a feature that has been proposed for upstream qemu, but not accepted yet; while it has probably stabilized to some degree, it may have minor tweaks. Conversely, I feel that the XML representation (the most important part to get right, since it becomes our API contract) is accurate and flexible enough to cover whatever minor modifiations qemu throws at us as followup patches to qemu_command.c. Daniel P. Berrange (1): spicevmc: support new qemu chardev Eric Blake (8): smartcard: add XML support for <smartcard> device smartcard: add domain conf support smartcard: check for qemu capability smartcard: enable SELinux support smartcard: turn on qemu support RFC: spicevmc: call out vdagent as a channel target Revert "RFC: spicevmc: call out vdagent as a channel target" smartcard: add spicevmc support cfg.mk | 1 + docs/formatdomain.html.in | 120 ++++++- docs/schemas/domain.rng | 70 ++++- src/conf/domain_conf.c | 395 +++++++++++++++++++- src/conf/domain_conf.h | 64 +++- src/libvirt_private.syms | 6 + src/qemu/qemu_capabilities.c | 17 +- src/qemu/qemu_capabilities.h | 3 + src/qemu/qemu_command.c | 154 +++++++- src/security/security_selinux.c | 76 ++++ tests/qemuhelpdata/qemu-kvm-0.12.1.2-rhel61 | 229 +++++++++++ tests/qemuhelpdata/qemu-kvm-0.12.1.2-rhel61-device | 74 ++++ tests/qemuhelptest.c | 43 +++ .../qemuxml2argv-channel-spicevmc.args | 9 + .../qemuxml2argv-channel-spicevmc.xml | 34 ++ .../qemuxml2argv-smartcard-controller.args | 7 + .../qemuxml2argv-smartcard-controller.xml | 19 + .../qemuxml2argv-smartcard-host-certificates.args | 8 + .../qemuxml2argv-smartcard-host-certificates.xml | 20 + .../qemuxml2argv-smartcard-host.args | 7 + .../qemuxml2argv-smartcard-host.xml | 16 + ...emuxml2argv-smartcard-passthrough-spicevmc.args | 7 + ...qemuxml2argv-smartcard-passthrough-spicevmc.xml | 16 + .../qemuxml2argv-smartcard-passthrough-tcp.args | 8 + .../qemuxml2argv-smartcard-passthrough-tcp.xml | 19 + tests/qemuxml2argvtest.c | 20 + 26 files changed, 1410 insertions(+), 32 deletions(-) create mode 100644 tests/qemuhelpdata/qemu-kvm-0.12.1.2-rhel61 create mode 100644 tests/qemuhelpdata/qemu-kvm-0.12.1.2-rhel61-device create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-channel-spicevmc.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-channel-spicevmc.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-smartcard-controller.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-smartcard-controller.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-smartcard-host-certificates.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-smartcard-host-certificates.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-smartcard-host.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-smartcard-host.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-smartcard-passthrough-spicevmc.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-smartcard-passthrough-spicevmc.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-smartcard-passthrough-tcp.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-smartcard-passthrough-tcp.xml -- 1.7.4

2 10

[libvirt] [PATCH] docs/index.html.in: update QEMU url
by Alon Levy 04 Feb '11

04 Feb '11

--- docs/index.html.in | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/docs/index.html.in b/docs/index.html.in index 501f3e3..30cc9d7 100644 --- a/docs/index.html.in +++ b/docs/index.html.in @@ -38,7 +38,7 @@ on Linux and Solaris hosts. </li> <li> - The <a href="http://bellard.org/qemu/">QEMU</a> emulator + The <a href="http://wiki.qemu.org/Index.html">QEMU</a> emulator </li> <li> The <a href="http://kvm.qumranet.com/kvmwiki">KVM</a> Linux hypervisor -- 1.7.4

2 1

[libvirt] [PATCH 0/2] Support booting from hostdev devices
by Jiri Denemark 03 Feb '11

03 Feb '11

These are a follow-up patches for per-device boot which extend current support for booting from disks and NICs to assigned host devices. Jiri Denemark (2): Support booting from hostdev devices qemu: Support booting from hostdev PCI devices docs/formatdomain.html.in | 14 ++++++++++++-- docs/schemas/domain.rng | 3 +++ src/conf/domain_conf.c | 18 +++++++++++++++--- src/conf/domain_conf.h | 1 + src/qemu/qemu_capabilities.c | 5 ++++- src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_command.c | 17 +++++++++++++++++ 7 files changed, 53 insertions(+), 6 deletions(-) -- 1.7.4

2 6

[libvirt] [PATCH v2] qemu: Add shortcut for HMP pass through
by Jiri Denemark 03 Feb '11

03 Feb '11

Currently users who want to use virDomainQemuMonitorCommand() API or it's virsh equivalent has to use the same protocol as libvirt uses for communication to qemu. Since the protocol is QMP with current qemu and HMP much more usable for humans, one ends up typing something like the following: virsh qemu-monitor-command DOM \ '{"execute":"human-monitor-command","arguments":{"command-line":"info kvm"}}' which is not a very convenient way of debugging qemu. This patch introduces --hmp option to qemu-monitor-command, which says that the provided command is in HMP. If libvirt uses QMP to talk with qemu, the command will automatically be converted into QMP. So the example above is simplified to just virsh qemu-monitor-command --hmp DOM "info kvm" Also the result is converted from {"return":"kvm support: enabled\r\n"} to just plain HMP: kvm support: enabled If libvirt talks to qemu in HMP, --hmp flag is obviously a noop. --- Notes: Version 2: - document --hmp in virsh man page - add missing virReportOOMError() in qemuMonitorArbitraryCommand() include/libvirt/libvirt-qemu.h | 5 +++++ src/internal.h | 1 + src/qemu/qemu_driver.c | 7 +++++-- src/qemu/qemu_monitor.c | 9 ++++++--- src/qemu/qemu_monitor.h | 5 ++++- src/qemu/qemu_monitor_json.c | 30 ++++++++++++++++++++++++++---- src/qemu/qemu_monitor_json.h | 3 ++- tools/virsh.c | 7 ++++++- tools/virsh.pod | 7 +++++-- 9 files changed, 60 insertions(+), 14 deletions(-) diff --git a/include/libvirt/libvirt-qemu.h b/include/libvirt/libvirt-qemu.h index 9c191c7..9257c2f 100644 --- a/include/libvirt/libvirt-qemu.h +++ b/include/libvirt/libvirt-qemu.h @@ -20,6 +20,11 @@ extern "C" { # endif +enum { + VIR_DOMAIN_QEMU_MONITOR_COMMAND_DEFAULT = 0, + VIR_DOMAIN_QEMU_MONITOR_COMMAND_HMP = (1 << 0), /* cmd is in HMP */ +} virDomainQemuMonitorCommandFlags; + int virDomainQemuMonitorCommand(virDomainPtr domain, const char *cmd, char **result, unsigned int flags); diff --git a/src/internal.h b/src/internal.h index 11ba45f..e263684 100644 --- a/src/internal.h +++ b/src/internal.h @@ -38,6 +38,7 @@ # define N_(str) str # include "libvirt/libvirt.h" +# include "libvirt/libvirt-qemu.h" # include "libvirt/virterror.h" # include "libvirt_internal.h" diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index a3a68b1..cce115a 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -10237,8 +10237,9 @@ static int qemuDomainMonitorCommand(virDomainPtr domain, const char *cmd, virDomainObjPtr vm = NULL; int ret = -1; qemuDomainObjPrivatePtr priv; + bool hmp; - virCheckFlags(0, -1); + virCheckFlags(VIR_DOMAIN_QEMU_MONITOR_COMMAND_HMP, -1); qemuDriverLock(driver); vm = virDomainFindByUUID(&driver->domains, domain->uuid); @@ -10264,10 +10265,12 @@ static int qemuDomainMonitorCommand(virDomainPtr domain, const char *cmd, priv->monitor_warned = 1; } + hmp = !!(flags & VIR_DOMAIN_QEMU_MONITOR_COMMAND_HMP); + if (qemuDomainObjBeginJobWithDriver(driver, vm) < 0) goto cleanup; qemuDomainObjEnterMonitorWithDriver(driver, vm); - ret = qemuMonitorArbitraryCommand(priv->mon, cmd, result); + ret = qemuMonitorArbitraryCommand(priv->mon, cmd, result, hmp); qemuDomainObjExitMonitorWithDriver(driver, vm); if (qemuDomainObjEndJob(vm) == 0) { vm = NULL; diff --git a/src/qemu/qemu_monitor.c b/src/qemu/qemu_monitor.c index 0c14277..fdb6b79 100644 --- a/src/qemu/qemu_monitor.c +++ b/src/qemu/qemu_monitor.c @@ -2007,14 +2007,17 @@ int qemuMonitorDeleteSnapshot(qemuMonitorPtr mon, const char *name) return ret; } -int qemuMonitorArbitraryCommand(qemuMonitorPtr mon, const char *cmd, char **reply) +int qemuMonitorArbitraryCommand(qemuMonitorPtr mon, + const char *cmd, + char **reply, + bool hmp) { int ret; - DEBUG("mon=%p, cmd=%s, reply=%p", mon, cmd, reply); + DEBUG("mon=%p, cmd=%s, reply=%p, hmp=%d", mon, cmd, reply, hmp); if (mon->json) - ret = qemuMonitorJSONArbitraryCommand(mon, cmd, reply); + ret = qemuMonitorJSONArbitraryCommand(mon, cmd, reply, hmp); else ret = qemuMonitorTextArbitraryCommand(mon, cmd, reply); return ret; diff --git a/src/qemu/qemu_monitor.h b/src/qemu/qemu_monitor.h index 92c550b..0ea1330 100644 --- a/src/qemu/qemu_monitor.h +++ b/src/qemu/qemu_monitor.h @@ -397,7 +397,10 @@ int qemuMonitorCreateSnapshot(qemuMonitorPtr mon, const char *name); int qemuMonitorLoadSnapshot(qemuMonitorPtr mon, const char *name); int qemuMonitorDeleteSnapshot(qemuMonitorPtr mon, const char *name); -int qemuMonitorArbitraryCommand(qemuMonitorPtr mon, const char *cmd, char **reply); +int qemuMonitorArbitraryCommand(qemuMonitorPtr mon, + const char *cmd, + char **reply, + bool hmp); /** * When running two dd process and using <> redirection, we need a diff --git a/src/qemu/qemu_monitor_json.c b/src/qemu/qemu_monitor_json.c index ca06e7e..d5e8d37 100644 --- a/src/qemu/qemu_monitor_json.c +++ b/src/qemu/qemu_monitor_json.c @@ -2457,22 +2457,44 @@ int qemuMonitorJSONDeleteSnapshot(qemuMonitorPtr mon, const char *name) int qemuMonitorJSONArbitraryCommand(qemuMonitorPtr mon, const char *cmd_str, - char **reply_str) + char **reply_str, + bool hmp) { virJSONValuePtr cmd = NULL; virJSONValuePtr reply = NULL; int ret = -1; - cmd = virJSONValueFromString(cmd_str); + if (!hmp) { + cmd = virJSONValueFromString(cmd_str); + } else { + cmd = qemuMonitorJSONMakeCommand("human-monitor-command", + "s:command-line", cmd_str, + NULL); + } + if (!cmd) return -1; if (qemuMonitorJSONCommand(mon, cmd, &reply) < 0) goto cleanup; - *reply_str = virJSONValueToString(reply); - if (!(*reply_str)) + if (!hmp) { + if (!(*reply_str = virJSONValueToString(reply))) + goto cleanup; + } else if (qemuMonitorJSONCheckError(cmd, reply)) { goto cleanup; + } else { + const char *data; + if (!(data = virJSONValueObjectGetString(reply, "return"))) { + qemuReportError(VIR_ERR_INTERNAL_ERROR, "%s", + _("human monitor command was missing return data")); + goto cleanup; + } + if (!(*reply_str = strdup(data))) { + virReportOOMError(); + goto cleanup; + } + } ret = 0; diff --git a/src/qemu/qemu_monitor_json.h b/src/qemu/qemu_monitor_json.h index 4c47f10..4ae472a 100644 --- a/src/qemu/qemu_monitor_json.h +++ b/src/qemu/qemu_monitor_json.h @@ -209,6 +209,7 @@ int qemuMonitorJSONDeleteSnapshot(qemuMonitorPtr mon, const char *name); int qemuMonitorJSONArbitraryCommand(qemuMonitorPtr mon, const char *cmd_str, - char **reply_str); + char **reply_str, + bool hmp); #endif /* QEMU_MONITOR_JSON_H */ diff --git a/tools/virsh.c b/tools/virsh.c index 59d099e..1f820e8 100644 --- a/tools/virsh.c +++ b/tools/virsh.c @@ -10176,6 +10176,7 @@ static const vshCmdInfo info_qemu_monitor_command[] = { static const vshCmdOptDef opts_qemu_monitor_command[] = { {"domain", VSH_OT_DATA, VSH_OFLAG_REQ, N_("domain name, id or uuid")}, {"cmd", VSH_OT_DATA, VSH_OFLAG_REQ, N_("command")}, + {"hmp", VSH_OT_BOOL, 0, N_("command is in human monitor protocol")}, {NULL, 0, 0, NULL} }; @@ -10186,6 +10187,7 @@ cmdQemuMonitorCommand(vshControl *ctl, const vshCmd *cmd) int ret = FALSE; char *monitor_cmd; char *result = NULL; + unsigned int flags = 0; if (!vshConnectionUsability(ctl, ctl->conn)) goto cleanup; @@ -10200,7 +10202,10 @@ cmdQemuMonitorCommand(vshControl *ctl, const vshCmd *cmd) goto cleanup; } - if (virDomainQemuMonitorCommand(dom, monitor_cmd, &result, 0) < 0) + if (vshCommandOptBool(cmd, "hmp")) + flags |= VIR_DOMAIN_QEMU_MONITOR_COMMAND_HMP; + + if (virDomainQemuMonitorCommand(dom, monitor_cmd, &result, flags) < 0) goto cleanup; printf("%s\n", result); diff --git a/tools/virsh.pod b/tools/virsh.pod index d6a16f2..bfaa67e 100644 --- a/tools/virsh.pod +++ b/tools/virsh.pod @@ -1253,10 +1253,13 @@ problems to the libvirt developers; the reports will be ignored. =over 4 -=item B<qemu-monitor-command> I<domain> I<command> +=item B<qemu-monitor-command> I<domain> I<command> optional I<--hmp> Send an arbitrary monitor command I<command> to domain I<domain> through the -qemu monitor. The results of the command will be printed on stdout. +qemu monitor. The results of the command will be printed on stdout. If +I<--hmp> is passed, the command is considered to be a human monitor command +and libvirt will automatically convert it into QMP if needed. In that case +the result will also be converted back from QMP. =back -- 1.7.4

2 2

[libvirt] [PATCH] macvtap.c: add parenthesis for similar expressions
by Davidlohr Bueso 03 Feb '11

03 Feb '11

It wouldn't hurt to add some parenthesis in the following two similar expression for better readability. --- src/util/macvtap.c | 8 ++++---- 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/src/util/macvtap.c b/src/util/macvtap.c index 09d7b78..92147ab 100644 --- a/src/util/macvtap.c +++ b/src/util/macvtap.c @@ -1048,8 +1048,8 @@ doPortProfileOpSetLink(bool nltarget_kernel, memcpy(ifla_vf_mac.mac, macaddr, 6); - if (!nla_put(nl_msg, IFLA_VF_MAC, sizeof(ifla_vf_mac), - &ifla_vf_mac) < 0) + if ((!nla_put(nl_msg, IFLA_VF_MAC, sizeof(ifla_vf_mac), + &ifla_vf_mac)) < 0) goto buffer_too_small; } @@ -1060,8 +1060,8 @@ doPortProfileOpSetLink(bool nltarget_kernel, .qos = 0, }; - if (!nla_put(nl_msg, IFLA_VF_VLAN, sizeof(ifla_vf_vlan), - &ifla_vf_vlan) < 0) + if ((!nla_put(nl_msg, IFLA_VF_VLAN, sizeof(ifla_vf_vlan), + &ifla_vf_vlan)) < 0) goto buffer_too_small; } -- 1.7.1

3 4

[libvirt] [PATCHv4 0/5] smartcard, round 4
by Eric Blake 03 Feb '11

03 Feb '11

This should address all of the comment from round 3: https://www.redhat.com/archives/libvir-list/2011-January/msg01034.html In particular, there is no longer a device tied to host mode (qemu uses NSS, which connects to the nss daemon rather than to a physical device); the certificate entries for host-certificates mode are no longer treated as paths, but as opaque names used within the database; the database defaults to /etc/pki/nssdb/ if not otherwise specified (hmm, I guess I haven't added support for $HOME/.pki/nssdb for non-root users yet, but wanted to get this out for review now due to a request from Alon). More notes on each patch. Eric Blake (5): smartcard: add XML support for <smartcard> device smartcard: add domain conf support smartcard: check for qemu capability smartcard: enable SELinux support smartcard: turn on qemu support cfg.mk | 1 + docs/formatdomain.html.in | 95 +++++- docs/schemas/domain.rng | 66 ++++ src/conf/domain_conf.c | 366 +++++++++++++++++++- src/conf/domain_conf.h | 52 +++- src/libvirt_private.syms | 4 + src/qemu/qemu_capabilities.c | 2 + src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_command.c | 95 +++++- src/security/security_selinux.c | 76 ++++ .../qemuxml2argv-smartcard-controller.args | 7 + .../qemuxml2argv-smartcard-controller.xml | 19 + .../qemuxml2argv-smartcard-host-certificates.args | 8 + .../qemuxml2argv-smartcard-host-certificates.xml | 20 + .../qemuxml2argv-smartcard-host.args | 7 + .../qemuxml2argv-smartcard-host.xml | 16 + .../qemuxml2argv-smartcard-passthrough-tcp.args | 7 + .../qemuxml2argv-smartcard-passthrough-tcp.xml | 19 + tests/qemuxml2argvtest.c | 13 + 19 files changed, 859 insertions(+), 15 deletions(-) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-smartcard-controller.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-smartcard-controller.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-smartcard-host-certificates.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-smartcard-host-certificates.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-smartcard-host.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-smartcard-host.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-smartcard-passthrough-tcp.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-smartcard-passthrough-tcp.xml -- 1.7.3.5

2 11

[libvirt] [PATCH 0/2] fix some bugs in libvirtd
by Wen Congyang 03 Feb '11

03 Feb '11

Steps to reproduce this bug: 1. service libvirtd start 2. virsh start <domain> 3. kill -STOP $(cat /var/run/libvirt/qemu/<domain>.pid) 4. service libvirtd restart 5. kill -9 $(cat /var/run/libvirt/qemu/<domain>.pid) Then libvirtd will core dump or be in deadlock state. Make sure that json is built into libvirt and the version of qemu is newer than 0.13.0. Wen Congyang (2): avoid vm to be deleted if qemuConnectMonitor failed avoid closing monitor twice src/qemu/qemu_driver.c | 31 ++++++++++++++++++++++--------- src/qemu/qemu_monitor.c | 10 ++++++++++ 2 files changed, 32 insertions(+), 9 deletions(-)

4 21

[libvirt] [PATCH] Fix conflicts with glibc globals
by Davidlohr Bueso 03 Feb '11

03 Feb '11

When compiling libvirt with GCC 3.4.6 the following warning is being triggered quite a lot: util/memory.h:60: warning: declaration of 'remove' shadows a global declaration /usr/include/stdio.h:175: warning: shadowed declaration is here Fix this by renaming the parameter to 'toremove'. --- src/util/memory.h | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/util/memory.h b/src/util/memory.h index 750a6b0..66b4c42 100644 --- a/src/util/memory.h +++ b/src/util/memory.h @@ -57,7 +57,7 @@ int virExpandN(void *ptrptr, size_t size, size_t *count, size_t add) int virResizeN(void *ptrptr, size_t size, size_t *alloc, size_t count, size_t desired) ATTRIBUTE_RETURN_CHECK ATTRIBUTE_NONNULL(1) ATTRIBUTE_NONNULL(3); -void virShrinkN(void *ptrptr, size_t size, size_t *count, size_t remove) +void virShrinkN(void *ptrptr, size_t size, size_t *count, size_t toremove) ATTRIBUTE_NONNULL(1) ATTRIBUTE_NONNULL(3); int virAllocVar(void *ptrptr, size_t struct_size, -- 1.7.1

2 1

[libvirt] [PATCH] Don't sleep in poll() if there is existing SASL decoded data
by Daniel P. Berrange 03 Feb '11

03 Feb '11

In the SASL codepath we typically read far more data off the wire than we immediately need. When using a connection from a single thread this isn't a problem, since only our reply will be pending (or an event we can handle directly). When using a connection from multiple threads though, we may read the data from replies from other threads. If those replies occur after our own reply, they'll not be processed. The other thread will then go into poll() and wait for its reply which has already been received and decoded. The solution is to set poll() timeout to 0 if there is pending SASL data. * src/remote/remote_driver.c: Don't sleep in poll() if SASL data exists --- src/remote/remote_driver.c | 16 +++++++++++++++- 1 files changed, 15 insertions(+), 1 deletions(-) diff --git a/src/remote/remote_driver.c b/src/remote/remote_driver.c index b52b780..452ab38 100644 --- a/src/remote/remote_driver.c +++ b/src/remote/remote_driver.c @@ -10222,6 +10222,14 @@ remoteIOEventLoop(virConnectPtr conn, #ifdef HAVE_PTHREAD_SIGMASK sigset_t oldmask, blockedsigs; #endif + int timeout = -1; + + /* If we have existing SASL decoded data we + * don't want to sleep in the poll(), just + * check if any other FDs are also ready + */ + if (priv->saslDecoded) + timeout = 0; fds[0].events = fds[0].revents = 0; fds[1].events = fds[1].revents = 0; @@ -10257,7 +10265,7 @@ remoteIOEventLoop(virConnectPtr conn, #endif repoll: - ret = poll(fds, ARRAY_CARDINALITY(fds), -1); + ret = poll(fds, ARRAY_CARDINALITY(fds), timeout); if (ret < 0 && errno == EAGAIN) goto repoll; @@ -10267,6 +10275,12 @@ remoteIOEventLoop(virConnectPtr conn, remoteDriverLock(priv); + /* If we have existing SASL decoded data, pretend + * the socket became readable so we consume it + */ + if (priv->saslDecoded) + fds[0].revents |= POLLIN; + if (fds[1].revents) { ssize_t s; DEBUG0("Woken up from poll by other thread"); -- 1.7.3.5

3 3

[libvirt] New sub-project libvirt-snmp
by Michal Prívozník 03 Feb '11

03 Feb '11

Hi, I'd like to let you know and review the new project libvirt-snmp. It's aim is to provide snmp functionality to libvirt. Right now it supports only VM lifecycle stuff (start, suspend, destroy, ...) and gathering info. The sources are available here: git clone git://libvirt.org/libvirt-snmp.git to install please see INSTALL file, some examples are in src/README.txt We can also create an .rpm (see libvirt-snmp.spec.in) but thing is in order to run libvirt-snmp subagent, snmpd.conf needs to be edited first. Is there a way I can solve this? I mean overwriting it is ugly. Or should i leave it just in the installation docs? Any suggestions appreciated. Michal Privoznik

2 1

[libvirt] [PATCH 0/3] Introduce QEMUD_CMD_FLAG_PCI_MULTIBUS for -device bus=pci(.0)
by Niels de Vos 03 Feb '11

03 Feb '11

This series introduces a new (fake) flag for the qemu binary. The flag QEMUD_CMD_FLAG_PCI_MULTIBUS is used to mark an architecture to be able to have multiple PCI-busses. When executing qemu, -device should take either a bus-string like "pci" or "pci.0". Where the latter can be used to select the appropriate bus for the PCI-device. Currently libvirt breaks starting qemu-system-$ARCH as the -device option always sets bus=pci.0. On most architectures, there is no PCI-Multibus support in qemu. This series enables libvirt to select the architectures that support PCI-multibus and sets the flag for x86_64 and i686 only. Reference: - https://bugzilla.redhat.com/show_bug.cgi?id=667345 Kind regards, Niels -- Niels de Vos (3): qemuBuildDeviceAddressStr() checks for QEMUD_CMD_FLAG_PCI_MULTIBUS Set QEMUD_CMD_FLAG_PCI_MULTIBUS for x86_64 and i686 architectures Add myself to AUTHORS AUTHORS | 1 + src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_command.c | 67 ++++++++++++++++++++++++++--------------- src/qemu/qemu_command.h | 18 +++++++---- src/qemu/qemu_hotplug.c | 5 ++- 5 files changed, 59 insertions(+), 33 deletions(-) -- 1.7.3.5

3 10

[libvirt] [PATCH] qemu: Add shortcut for HMP pass through
by Jiri Denemark 03 Feb '11

03 Feb '11

Currently users who want to use virDomainQemuMonitorCommand() API or it's virsh equivalent has to use the same protocol as libvirt uses for communication to qemu. Since the protocol is QMP with current qemu and HMP much more usable for humans, one ends up typing something like the following: virsh qemu-monitor-command DOM \ '{"execute":"human-monitor-command","arguments":{"command-line":"info kvm"}}' which is not a very convenient way of debugging qemu. This patch introduces --hmp option to qemu-monitor-command, which says that the provided command is in HMP. If libvirt uses QMP to talk with qemu, the command will automatically be converted into QMP. So the example above is simplified to just virsh qemu-monitor-command --hmp DOM "info kvm" Also the result is converted from {"return":"kvm support: enabled\r\n"} to just plain HMP: kvm support: enabled If libvirt talks to qemu in HMP, --hmp flag is obviously a noop. --- include/libvirt/libvirt-qemu.h | 5 +++++ src/internal.h | 1 + src/qemu/qemu_driver.c | 7 +++++-- src/qemu/qemu_monitor.c | 9 ++++++--- src/qemu/qemu_monitor.h | 5 ++++- src/qemu/qemu_monitor_json.c | 27 ++++++++++++++++++++++++--- src/qemu/qemu_monitor_json.h | 3 ++- tools/virsh.c | 7 ++++++- 8 files changed, 53 insertions(+), 11 deletions(-) diff --git a/include/libvirt/libvirt-qemu.h b/include/libvirt/libvirt-qemu.h index 9c191c7..9257c2f 100644 --- a/include/libvirt/libvirt-qemu.h +++ b/include/libvirt/libvirt-qemu.h @@ -20,6 +20,11 @@ extern "C" { # endif +enum { + VIR_DOMAIN_QEMU_MONITOR_COMMAND_DEFAULT = 0, + VIR_DOMAIN_QEMU_MONITOR_COMMAND_HMP = (1 << 0), /* cmd is in HMP */ +} virDomainQemuMonitorCommandFlags; + int virDomainQemuMonitorCommand(virDomainPtr domain, const char *cmd, char **result, unsigned int flags); diff --git a/src/internal.h b/src/internal.h index 038b862..dc1d9cb 100644 --- a/src/internal.h +++ b/src/internal.h @@ -38,6 +38,7 @@ # define N_(str) str # include "libvirt/libvirt.h" +# include "libvirt/libvirt-qemu.h" # include "libvirt/virterror.h" # include "libvirt_internal.h" diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index 23e0db0..bb50264 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -10226,8 +10226,9 @@ static int qemuDomainMonitorCommand(virDomainPtr domain, const char *cmd, virDomainObjPtr vm = NULL; int ret = -1; qemuDomainObjPrivatePtr priv; + bool hmp; - virCheckFlags(0, -1); + virCheckFlags(VIR_DOMAIN_QEMU_MONITOR_COMMAND_HMP, -1); qemuDriverLock(driver); vm = virDomainFindByUUID(&driver->domains, domain->uuid); @@ -10253,10 +10254,12 @@ static int qemuDomainMonitorCommand(virDomainPtr domain, const char *cmd, priv->monitor_warned = 1; } + hmp = !!(flags & VIR_DOMAIN_QEMU_MONITOR_COMMAND_HMP); + if (qemuDomainObjBeginJobWithDriver(driver, vm) < 0) goto cleanup; qemuDomainObjEnterMonitorWithDriver(driver, vm); - ret = qemuMonitorArbitraryCommand(priv->mon, cmd, result); + ret = qemuMonitorArbitraryCommand(priv->mon, cmd, result, hmp); qemuDomainObjExitMonitorWithDriver(driver, vm); if (qemuDomainObjEndJob(vm) == 0) { vm = NULL; diff --git a/src/qemu/qemu_monitor.c b/src/qemu/qemu_monitor.c index 0c14277..fdb6b79 100644 --- a/src/qemu/qemu_monitor.c +++ b/src/qemu/qemu_monitor.c @@ -2007,14 +2007,17 @@ int qemuMonitorDeleteSnapshot(qemuMonitorPtr mon, const char *name) return ret; } -int qemuMonitorArbitraryCommand(qemuMonitorPtr mon, const char *cmd, char **reply) +int qemuMonitorArbitraryCommand(qemuMonitorPtr mon, + const char *cmd, + char **reply, + bool hmp) { int ret; - DEBUG("mon=%p, cmd=%s, reply=%p", mon, cmd, reply); + DEBUG("mon=%p, cmd=%s, reply=%p, hmp=%d", mon, cmd, reply, hmp); if (mon->json) - ret = qemuMonitorJSONArbitraryCommand(mon, cmd, reply); + ret = qemuMonitorJSONArbitraryCommand(mon, cmd, reply, hmp); else ret = qemuMonitorTextArbitraryCommand(mon, cmd, reply); return ret; diff --git a/src/qemu/qemu_monitor.h b/src/qemu/qemu_monitor.h index 92c550b..0ea1330 100644 --- a/src/qemu/qemu_monitor.h +++ b/src/qemu/qemu_monitor.h @@ -397,7 +397,10 @@ int qemuMonitorCreateSnapshot(qemuMonitorPtr mon, const char *name); int qemuMonitorLoadSnapshot(qemuMonitorPtr mon, const char *name); int qemuMonitorDeleteSnapshot(qemuMonitorPtr mon, const char *name); -int qemuMonitorArbitraryCommand(qemuMonitorPtr mon, const char *cmd, char **reply); +int qemuMonitorArbitraryCommand(qemuMonitorPtr mon, + const char *cmd, + char **reply, + bool hmp); /** * When running two dd process and using <> redirection, we need a diff --git a/src/qemu/qemu_monitor_json.c b/src/qemu/qemu_monitor_json.c index ca06e7e..9ac12f8 100644 --- a/src/qemu/qemu_monitor_json.c +++ b/src/qemu/qemu_monitor_json.c @@ -2457,20 +2457,41 @@ int qemuMonitorJSONDeleteSnapshot(qemuMonitorPtr mon, const char *name) int qemuMonitorJSONArbitraryCommand(qemuMonitorPtr mon, const char *cmd_str, - char **reply_str) + char **reply_str, + bool hmp) { virJSONValuePtr cmd = NULL; virJSONValuePtr reply = NULL; int ret = -1; - cmd = virJSONValueFromString(cmd_str); + if (!hmp) { + cmd = virJSONValueFromString(cmd_str); + } else { + cmd = qemuMonitorJSONMakeCommand("human-monitor-command", + "s:command-line", cmd_str, + NULL); + } + if (!cmd) return -1; if (qemuMonitorJSONCommand(mon, cmd, &reply) < 0) goto cleanup; - *reply_str = virJSONValueToString(reply); + if (!hmp) { + *reply_str = virJSONValueToString(reply); + } else if (qemuMonitorJSONCheckError(cmd, reply)) { + goto cleanup; + } else { + const char *data; + if (!(data = virJSONValueObjectGetString(reply, "return"))) { + qemuReportError(VIR_ERR_INTERNAL_ERROR, "%s", + _("human monitor command was missing return data")); + goto cleanup; + } + *reply_str = strdup(data); + } + if (!(*reply_str)) goto cleanup; diff --git a/src/qemu/qemu_monitor_json.h b/src/qemu/qemu_monitor_json.h index 4c47f10..4ae472a 100644 --- a/src/qemu/qemu_monitor_json.h +++ b/src/qemu/qemu_monitor_json.h @@ -209,6 +209,7 @@ int qemuMonitorJSONDeleteSnapshot(qemuMonitorPtr mon, const char *name); int qemuMonitorJSONArbitraryCommand(qemuMonitorPtr mon, const char *cmd_str, - char **reply_str); + char **reply_str, + bool hmp); #endif /* QEMU_MONITOR_JSON_H */ diff --git a/tools/virsh.c b/tools/virsh.c index 4533d38..59d3de5 100644 --- a/tools/virsh.c +++ b/tools/virsh.c @@ -9932,6 +9932,7 @@ static const vshCmdInfo info_qemu_monitor_command[] = { static const vshCmdOptDef opts_qemu_monitor_command[] = { {"domain", VSH_OT_DATA, VSH_OFLAG_REQ, N_("domain name, id or uuid")}, {"cmd", VSH_OT_DATA, VSH_OFLAG_REQ, N_("command")}, + {"hmp", VSH_OT_BOOL, 0, N_("command is in human monitor protocol")}, {NULL, 0, 0, NULL} }; @@ -9942,6 +9943,7 @@ cmdQemuMonitorCommand(vshControl *ctl, const vshCmd *cmd) int ret = FALSE; char *monitor_cmd; char *result = NULL; + unsigned int flags = 0; if (!vshConnectionUsability(ctl, ctl->conn)) goto cleanup; @@ -9956,7 +9958,10 @@ cmdQemuMonitorCommand(vshControl *ctl, const vshCmd *cmd) goto cleanup; } - if (virDomainQemuMonitorCommand(dom, monitor_cmd, &result, 0) < 0) + if (vshCommandOptBool(cmd, "hmp")) + flags |= VIR_DOMAIN_QEMU_MONITOR_COMMAND_HMP; + + if (virDomainQemuMonitorCommand(dom, monitor_cmd, &result, flags) < 0) goto cleanup; printf("%s\n", result); -- 1.7.4

2 2

[libvirt] [PATCH] Add check for binary existing in machine type probe
by Daniel P. Berrange 02 Feb '11

02 Feb '11

When probing machine types if the QEMU binary does not exist we get a hard to diagnose error, due to the execve() in the child failing error: internal error Child process exited with status 1. Add an explicit check so that we get error: Cannot find QEMU binary /usr/libexec/qem3u-kvm: No such file or directory * src/qemu/qemu_capabilities.c: Check for QEMU binary --- src/qemu/qemu_capabilities.c | 9 +++++++++ 1 files changed, 9 insertions(+), 0 deletions(-) diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c index 37a97aa..08c46be 100644 --- a/src/qemu/qemu_capabilities.c +++ b/src/qemu/qemu_capabilities.c @@ -172,6 +172,15 @@ qemuCapsProbeMachineTypes(const char *binary, int ret = -1; virCommandPtr cmd; + /* Make sure the binary we are about to try exec'ing exists. + * Technically we could catch the exec() failure, but that's + * in a sub-process so it's hard to feed back a useful error. + */ + if (access(binary, X_OK) < 0) { + virReportSystemError(errno, _("Cannot find QEMU binary %s"), binary); + return -1; + } + cmd = virCommandNewArgList(binary, "-M", "?", NULL); virCommandAddEnvPassCommon(cmd); virCommandSetOutputBuffer(cmd, &output); -- 1.7.3.5

2 1

[libvirt] [PATCH] Add a little more debugging for async events
by Daniel P. Berrange 02 Feb '11

02 Feb '11

To make it easier to investigate problems with async event delivery, add two more debugging lines * daemon/remote.c: Debug when an event is queued for dispatch * src/remote/remote_driver.c: Debug when an event is received for processing --- daemon/remote.c | 2 ++ src/remote/remote_driver.c | 1 + 2 files changed, 3 insertions(+), 0 deletions(-) diff --git a/daemon/remote.c b/daemon/remote.c index aa6a1a4..f8f6ffa 100644 --- a/daemon/remote.c +++ b/daemon/remote.c @@ -5670,6 +5670,8 @@ remoteDispatchDomainEventSend (struct qemud_client *client, msg->async = 1; msg->bufferLength = len; msg->bufferOffset = 0; + + VIR_DEBUG("Queue event %d %d", procnr, msg->bufferLength); qemudClientMessageQueuePush(&client->tx, msg); qemudUpdateClientEvent(client); diff --git a/src/remote/remote_driver.c b/src/remote/remote_driver.c index 347b844..64af91c 100644 --- a/src/remote/remote_driver.c +++ b/src/remote/remote_driver.c @@ -9865,6 +9865,7 @@ processCallDispatch(virConnectPtr conn, struct private_data *priv, break; case REMOTE_MESSAGE: /* Async notifications */ + VIR_DEBUG("Dispatch event %d %d", hdr.proc, priv->bufferLength); rv = processCallDispatchMessage(conn, priv, flags & REMOTE_CALL_IN_OPEN, &hdr, &xdr); break; -- 1.7.3.5

2 1

[libvirt] [PATCH] docs: more on qemu locking patterns
by Eric Blake 02 Feb '11

02 Feb '11

* src/qemu/THREADS.txt: Improve documentation. --- I'm trying to make sure we don't have any qemu locking gotchas, given that I've had a bug report of a qemu monitor callback being able to result in a domaing being unreferenced while in the middle of another command. As a first shot, I found that our documentation needed some help. Also, I have a question. I updated the documentation to match existing code: qemuDomainObjExitMonitor() - - Acquires the virDomainObjPtr lock - Releases the qemuMonitorObjPtr lock + - Acquires the virDomainObjPtr lock But I'm wondering if that was correct, or if the code should instead be swapped to match the original ordering in the documentation. src/qemu/THREADS.txt | 100 ++++++++++++++++++++++++++++++++++++++----------- 1 files changed, 77 insertions(+), 23 deletions(-) diff --git a/src/qemu/THREADS.txt b/src/qemu/THREADS.txt index 1af1b83..1e0b5ab 100644 --- a/src/qemu/THREADS.txt +++ b/src/qemu/THREADS.txt @@ -4,7 +4,7 @@ This document describes how thread safety is ensured throughout the QEMU driver. The criteria for this model are: - - Objects must never be exclusively locked for any pro-longed time + - Objects must never be exclusively locked for any prolonged time - Code which sleeps must be able to time out after suitable period - Must be safe against dispatch asynchronous events from monitor @@ -36,11 +36,11 @@ There are a number of locks on various objects Once the lock is held, you must *NOT* try to lock the driver. You must release all virDomainObjPtr locks before locking the driver, or deadlock - *WILL* occurr. + *WILL* occur. If the lock needs to be dropped & then re-acquired for a short period of time, the reference count must be incremented first using virDomainObjRef(). - If the reference count is incremented in this way, it is not neccessary + If the reference count is incremented in this way, it is not necessary to have the driver locked when re-acquiring the dropped locked, since the reference count prevents it being freed by another thread. @@ -51,15 +51,20 @@ There are a number of locks on various objects * qemuMonitorPrivatePtr: Job condition - Since virDomainObjPtr lock must not be held during sleeps, the job condition - provides additional protection for code making updates. + Since virDomainObjPtr lock must not be held during sleeps, the job + condition provides additional protection for code making updates. - Immediately after acquiring the virDomainObjPtr lock, any method which intends - to update state, must acquire the job condition. The virDomainObjPtr lock - is released while blocking on this condition variable. Once the job condition - is acquired a method can safely release the virDomainObjPtr lock whenever it - hits a piece of code which may sleep/wait, and re-acquire it after the sleep/ - wait. + Immediately after acquiring the virDomainObjPtr lock, any method + which intends to update state must acquire the job condition. The + virDomainObjPtr lock is released while blocking on this condition + variable. Once the job condition is acquired, a method can safely + release the virDomainObjPtr lock whenever it hits a piece of code + which may sleep/wait, and re-acquire it after the sleep/wait. + + Since the virDomainObjPtr lock was dropped while waiting for the + job condition, it is possible that the domain is no longer active + when the condition is finally obtained. The monitor lock is only + safe to grab after verifying that the domain is still active. * qemuMonitorPtr: Mutex @@ -110,13 +115,15 @@ To acquire the job mutex qemuDomainObjBeginJob() (if driver is unlocked) - Increments ref count on virDomainObjPtr - - Wait qemuDomainObjPrivate condition 'jobActive != 0' using virDomainObjPtr mutex + - Wait qemuDomainObjPrivate condition 'jobActive != 0' using + virDomainObjPtr mutex - Sets jobActive to 1 qemuDomainObjBeginJobWithDriver() (if driver needs to be locked) - Unlocks driver - Increments ref count on virDomainObjPtr - - Wait qemuDomainObjPrivate condition 'jobActive != 0' using virDomainObjPtr mutex + - Wait qemuDomainObjPrivate condition 'jobActive != 0' using + virDomainObjPtr mutex - Sets jobActive to 1 - Unlocks virDomainObjPtr - Locks driver @@ -140,10 +147,10 @@ To acquire the QEMU monitor lock - Releases the virDomainObjPtr lock qemuDomainObjExitMonitor() - - Acquires the virDomainObjPtr lock - Releases the qemuMonitorObjPtr lock + - Acquires the virDomainObjPtr lock - NB: caller must take care to drop the driver lock if neccessary + NB: caller must take care to drop the driver lock if necessary To acquire the QEMU monitor lock with the driver lock held @@ -154,11 +161,25 @@ To acquire the QEMU monitor lock with the driver lock held - Releases the driver lock qemuDomainObjExitMonitorWithDriver() + - Releases the qemuMonitorObjPtr lock - Acquires the driver lock - Acquires the virDomainObjPtr lock - - Releases the qemuMonitorObjPtr lock - NB: caller must take care to drop the driver lock if neccessary + NB: caller must take care to drop the driver lock if necessary + + +To keep a domain alive while waiting on a remote command, starting +with the driver lock held + + qemuDomainObjEnterRemoterWithDriver() + - Increments ref count on virDomainObjPtr + - Releases the virDomainObjPtr lock + - Releases the driver lock + + qemuDomainObjExitRemoteWithDriver() + - Acquires the driver lock + - Acquires the virDomainObjPtr lock + - Decrements ref count on virDomainObjPtr Design patterns @@ -236,9 +257,11 @@ Design patterns ...do prep work... - qemuDomainObjEnterMonitor(obj); - qemuMonitorXXXX(priv->mon); - qemuDomainObjExitMonitor(obj); + if (virDomainObjIsActive(vm)) { + qemuDomainObjEnterMonitor(obj); + qemuMonitorXXXX(priv->mon); + qemuDomainObjExitMonitor(obj); + } ...do final work... @@ -261,9 +284,11 @@ Design patterns ...do prep work... - qemuDomainObjEnterMonitorWithDriver(driver, obj); - qemuMonitorXXXX(priv->mon); - qemuDomainObjExitMonitorWithDriver(driver, obj); + if (virDomainObjIsActive(vm)) { + qemuDomainObjEnterMonitorWithDriver(driver, obj); + qemuMonitorXXXX(priv->mon); + qemuDomainObjExitMonitorWithDriver(driver, obj); + } ...do final work... @@ -272,6 +297,35 @@ Design patterns qemuDriverUnlock(driver); + * Coordinating with a remote server for migraion + + virDomainObjPtr obj; + qemuDomainObjPrivatePtr priv; + + qemuDriverLock(driver); + obj = virDomainFindByUUID(driver->domains, dom->uuid); + + qemuDomainObjBeginJobWithDriver(obj); + + ...do prep work... + + if (virDomainObjIsActive(vm)) { + qemuDomainObjEnterRemoteWithDriver(driver, obj); + ...communicate with remote... + qemuDomainObjExitRemoteWithDriver(driver, obj); + /* domain may have been stopped while we were talking to remote */ + if (!virDomainObjIsActive(vm)) { + qemuReportError(VIR_ERR_INTERNAL_ERROR, "%s", + _("guest unexpectedly quit")); + } + } + + ...do final work... + + qemuDomainObjEndJob(obj); + virDomainObjUnlock(obj); + qemuDriverUnlock(driver); + Summary ------- -- 1.7.3.5

2 2

[libvirt] Strange nodedev-dumpxml ??
by arnaud.champion＠devatom.fr 02 Feb '11

02 Feb '11

?Hi, I have maybe a strange thing on a nodedev-dumpxml virsh result : virsh # nodedev-dumpxml block_sr0 <device> <name>block_sr0</name> <parent>scsi_0_0_1_0</parent> <capability type='storage'> <block>/dev/sr0</block> <bus>scsi</bus> <drive_type>cdrom</drive_type> <model>DVD RW DRU-190S</model> <vendor>SONY</vendor> <capability type='removable'> <media_available>0</media_available> <media_size>0</media_size> </capability> </capability> </device> I think (note I'm not sure), the capabilty type removable should be in the device element, like this : virsh # nodedev-dumpxml block_sr0 <device> <name>block_sr0</name> <parent>scsi_0_0_1_0</parent> <capability type='storage'> <block>/dev/sr0</block> <bus>scsi</bus> <drive_type>cdrom</drive_type> <model>DVD RW DRU-190S</model> <vendor>SONY</vendor> </capability> <capability type='removable'> <media_available>0</media_available> <media_size>0</media_size> </capability> </device> Let me know if I'm wrong. Regards, Arnaud

1 0

[libvirt] Node devices capability xml
by arnaud.champion＠devatom.fr 02 Feb '11

02 Feb '11

?Hi, I'm looking for informations about node devices capibility xml (not driver capabilities), and there's nothing on libvirt.org, can anyone can point me to find the infos ? regards, Arnaud

1 0

[libvirt] nodedev-list and qemu
by arnaud.champion＠devatom.fr 02 Feb '11

02 Feb '11

?Hi, I've just installed libvirt 0.8.7 on my fedora x86_64 14 test host. It seems that the function virNodeNumOfDevices is no more supported by the qemu driver. Is that true ? or I'm wrong anywhere ? Regards, Arnaud

2 2