Skip to content

L
libvirt

openeuler / libvirt

通知 3
Star 0
Fork 0
L
libvirt

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 08 7月, 2015 1 次提交
  3. 07 7月, 2015 1 次提交
    • M
      vz: assign static IPs and default gateways for network adapter · beddef39
      由 Mikhail Feoktistov 提交于 
      We support only one IPv4 and one IPv6 default gateway.
If static IPs are not present in instance config,
then we switch on DHCP for this adapter.
PrlVmDevNet_SetAutoApply to makes necessary settings within guest OS
In linux case it creates network startup scripts
/etc/sysconfig/network-scripts/ifcfg-ethN and fills it with necessary
parameters.
      beddef39
  5. 06 7月, 2015 1 次提交
    • D
      vz: fix building capabilities · 651426e9
      由 Dmitry Guryanov 提交于 
      There should be at least one domain for each guest
in cababilities. And in current code we don't add
domain for this guest for example.

    if ((guest = virCapabilitiesAddGuest(caps, VIR_DOMAIN_OSTYPE_HVM,
                                         VIR_ARCH_X86_64,
                                         "vz",
                                         NULL, 0, NULL)) == NULL)

Anyway, with two virt types it looks a litte messy, so let's
move adding guest and domain to a separate function.
Signed-off-by: NDmitry Guryanov <dguryanov@parallels.com>
      651426e9
  7. 03 7月, 2015 3 次提交
  9. 02 7月, 2015 31 次提交
  11. 01 7月, 2015 3 次提交
    • M
      lxc: Don't pass a local variable address randomly · 302146b1
      由 Michal Privoznik 提交于 
      So, recently I was testing the LXC driver. You know, startup some
domains. But to my surprise, I was not able to start a single one:

  virsh # start --console test
  error: Reconnected to the hypervisor
  error: Failed to start domain test
  error: internal error: guest failed to start: unexpected exit status 125

So I've start digging. It turns out, that in virExec(), when I printed
out the @cmd, I got strange values: *(cmd->outfdptr) was certainly not
valid FD number: it has random value of several millions. This
obviously made prepareStdFd(childout, STDOUT_FILENO) fail (line 611).
But outfdptr is set in virCommandSetOutputFD(). The only place within
LXC driver where the function is called is in
virLXCProcessBuildControllerCmd(). If you take a closer look at the
function it looks like this:

static virCommandPtr
virLXCProcessBuildControllerCmd(virLXCDriverPtr driver,
                                ..
                                int logfd,
                                const char *pidfile)
{
    ...
    virCommandSetOutputFD(cmd, &logfd);
    virCommandSetErrorFD(cmd, &logfd);
    ...
}

Yes, you guessed it. @logfd is passed into the function by value.
However, in the function we try to get its address (an address of a
local variable) which is no longer valid once function is finished and
stack is cleaned. Therefore when cmd->outfdptr is evaluated at any
point after this function, we may get a random number, depending on
what's currently on the stack. Of course, this may work sometimes too
- it depends on the compiler how it arranges the code, when the stack
is wiped out.

In order to fix this, lets pass a pointer to @logfd instead of
figuring out (wrong) its value in a function.

The bug was introduced in e1de5521.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      302146b1
    • J
      qemu: Resolve Coverity DEADCODE · ebd62eba
      由 John Ferlan 提交于 
      Commit id 'f967e7a6' didn't place the closing parentheses quite right
causing DEADCODE errors since the rc setting/comparison was wrong.
      ebd62eba
    • P
      conf: qemu: Taint VMs using custom device tree blob · 4b48ba4a
      由 Peter Krempa 提交于 
      Using a custom device tree image may cause unexpected behavior in
architectures that use this approach to detect platform devices. Since
usually the device tree is generated by qemu and thus it's not normally
used let's taint VMs using it to make it obvious as a possible source of
problems.
      4b48ba4a