Skip to content

L
libvirt

openeuler / libvirt

通知 3
Star 0
Fork 0
L
libvirt

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

切换分支/标签
  1. 24 12月, 2015 2 次提交
    • M
      vz: move prlsdkCleanupBridgedNet after domain deletion · 64b3bb7b
      由 Maxim Nestratov 提交于 
      prlsdkCleanupBridgedNet call should be made strongly after
any actual domain deletion accurs. By doing this we avoid
any potential problems connected with second undefine call
when it is made after first one fails by some reason, and
we detect that network is already deleted.
Signed-off-by: NMaxim Nestratov <mnestratov@virtuozzo.com>
      64b3bb7b
    • M
      vz: delete domains when undefine is called · b7337394
      由 Maxim Nestratov 提交于 
      Currently vz driver unregisters domains when undefine is called,
which is wrong because it contradicts with expected behavior.
All vz domains are persistent, which means that when one is
defined a new bundle directory containing meta data is created.
Undefining domains in a way we do now leaves those directories
undeleted, which prevents subsequent define call for the same
domain xml. I.e. the following sequence define->undefine->define
doesn't work now.
The patch fixes the problem by calling PrlVm_Delete instead of
PrlVm_Unreg detaching all disks prior actually doing this to
prevent images deletion.
Signed-off-by: NMaxim Nestratov <mnestratov@virtuozzo.com>
      b7337394
  3. 21 12月, 2015 7 次提交
    • A
      hostdev: Emit debug messages while handling PCI hostdevs · d5a0cf10
      由 Andrea Bolognani 提交于 
      Both detach and reattach are complex operations involving several steps,
and it can be useful to be able to follow along by reading the log.
      d5a0cf10
    • A
      hostdev: Only rollback detach of managed devices on error · e926df60
      由 Andrea Bolognani 提交于 
      Since we don't detach unmanaged devices before attaching them to a
domain, we shouldn't reattach them to rollback an error either.
      e926df60
    • A
      hostdev: Mark PCI devices as inactive as they're detached · b8a625f3
      由 Andrea Bolognani 提交于 
      We want to eventually factor out the code dealing with device detaching
and reattaching, so that we can share it and make sure it's called eg.
when 'virsh nodedev-detach' is used.

For that to happen, it's important that the lists of active and inactive
PCI devices are updated every time a device changes its state.

Instead of passing NULL as the last argument of virPCIDeviceDetach() and
virPCIDeviceReattach(), pass the proper list so that it can be updated.
      b8a625f3
    • A
      pci: Introduce virPCIStubDriver enumeration · 6d9cdd2a
      由 Andrea Bolognani 提交于 
      This replaces the virPCIKnownStubs string array that was used
internally for stub driver validation.

Advantages:

  * possible values are well-defined
  * typos in driver names will be detected at compile time
  * avoids having several copies of the same string around
  * no error checking required when setting / getting value

The names used mirror those in the
virDomainHostdevSubsysPCIBackendType enumeration.
      6d9cdd2a
    • A
      pci: Remove 'reprobe' parameter from virPCIDeviceUnbind() · e1b24583
      由 Andrea Bolognani 提交于 
      The value is not inspected inside the function, so it makes more
sense for the caller to change the device's setting explicitly.
      e1b24583
    • A
      pci: Remove redundant parameter from virPCIDeviceBindToStub() · 51f39c70
      由 Andrea Bolognani 提交于 
      This internal function supports, in theory, binding to a different
stub driver than the one the PCI device has been configured to use.

In practice, it is only ever called like

  virPCIDeviceBindToStub(dev, dev->stubDriver);

which makes its second parameter redundant. Get rid of it, along
with the extra string copy required to support it.
      51f39c70
    • E
      Revert "admin: Rename virAdmConnect to virAdmDaemon" · 3245e178
      由 Erik Skultety 提交于 
      Commmit df8192aa introduced admin related rename and some minor
(caused by automated approach, aka sed) and some more severe isues along with
it. First reason to revert is the inconsistency with libvirt library.
Although we deal with the daemon directly rather than with a specific
hypervisor, we still do have a connection. That being said, contributors might
get under the impression that AdmDaemonNew would spawn/start a new daemon
(since it's admin API, why not...), or AdmDaemonClose would do the exact
opposite or they might expect DaemonIsAlive report overall status of the daemon
which definitely isn't the case.
The second reason to revert this patch is renaming virt-admin client. The
client tool does not necessarily have to reflect the names of the API's it's
using in his internals. An example would be 's/vshAdmConnect/vshAdmDaemon'
where noone can be certain of what the latter function really does. The former
is quite expressive about some connection magic it performs, but the latter does
not say anything, especially when vshAdmReconnect and vshAdmDisconnect were
left untouched.
      3245e178
  5. 19 12月, 2015 1 次提交
    • J
      Xen: support maxvcpus in xm and xl config · 5b74103b
      由 Jim Fehlig 提交于 
      From: Ian Campbell <ian.campbell@citrix.com>

xend prior to 4.0 understands vcpus as maxvcpus and vcpu_avail
as a bit map of which cpus are online (default is all).

xend from 4.0 onwards understands maxvcpus as maxvcpus and
vcpus as the number which are online (from 0..N-1). The
upstream commit (68a94cf528e6 "xm: Add maxvcpus support")
claims that if maxvcpus is omitted then the old behaviour
(i.e. obeying vcpu_avail) is retained, but AFAICT it was not,
in this case vcpu==maxcpus==online cpus. This is good for us
because handling anything else would be fiddly.

This patch changes parsing of the virDomainDef maxvcpus and vcpus
entries to use the corresponding 'maxvcpus' and 'vcpus' settings
from xm and xl config. It also drops use of the old Xen 3.x
'vcpu_avail' setting.

The change also removes the maxvcpus limit of MAX_VIRT_VCPUS (since
maxvcpus is simply a count, not a bit mask), which is particularly
crucial on ARM where MAX_VIRT_CPUS == 1 (since all guests are
expected to support vcpu placement, and therefore only the boot
vcpu's info lives in the shared info page).

Existing tests adjusted accordingly, and new tests added for the
'maxvcpus' setting.
      5b74103b
  7. 18 12月, 2015 26 次提交
  9. 17 12月, 2015 4 次提交