Sync master to feature branch#7127
Closed
liulinC wants to merge 44 commits into
Closed
Conversation
Gate the checks done for the other_config keys task_id and related_to to VBDs associated with control domains Signed-off-by: Pau Ruiz Safont <pau.safont@vates.tech>
Looks like this mechanism was used in the past, and only one vestigial check on VBD creation was used. It does not make sense to create a VBD associated with a task and immediately check whether it has leaked. Signed-off-by: Pau Ruiz Safont <pau.safont@vates.tech>
Signed-off-by: Seb Hinderer <sebastien.hinderer@vates.tech>
used for running dune in a build root without conflicting with the
normal _build that is used by editors or other tools
This separate directory can be used by setting an environment variable:
DUNE_BUILD_DIR=_mock dune build ocaml/quicktest/ --profile=release -w
Signed-off-by: Pau Ruiz Safont <pau.safont@vates.tech>
(cherry picked from commit dc1779b)
This module can help with printing API types, so move it to a new private library so it can be used without compiling the cli server. This is especially interesting for unit tests. Signed-off-by: Pau Ruiz Safont <pau.safont@vates.tech> (cherry picked from commit 369adb4)
Signed-off-by: Pau Ruiz Safont <pau.safont@vates.tech> (cherry picked from commit 390e484)
Makes the distinction between the absence of a value and absence of an error. Signed-off-by: Pau Ruiz Safont <pau.safont@vates.tech> (cherry picked from commit dbc6230)
The lists of operations used in the module need to be a subset of all_ops, otherwise spurious errors can be thrown on runtime. Ensuring these properties allows to drop the runtime check Also add an interface file for the module Signed-off-by: Pau Ruiz Safont <pau.safont@vates.tech> (cherry picked from commit 9edae93)
avoids having unused bindings Signed-off-by: Pau Ruiz Safont <pau.safont@vates.tech> (cherry picked from commit 2a93795)
That's pre-2009 in xapi land Signed-off-by: Pau Ruiz Safont <pau.safont@vates.tech> (cherry picked from commit 4f7a66e)
No change in behaviour Signed-off-by: Pau Ruiz Safont <pau.safont@vates.tech> (cherry picked from commit 797bf5f)
Signed-off-by: Pau Ruiz Safont <pau.safont@vates.tech> (cherry picked from commit 58b88f2)
Signed-off-by: Pau Ruiz Safont <pau.safont@vates.tech> (cherry picked from commit 44366b7)
VDIs containing only CDs are immutable and are prevented from being cloned. Signed-off-by: Pau Ruiz Safont <pau.safont@vates.tech> (cherry picked from commit 625226b)
This is preparation for using VDI.revert. No change in behaviour Signed-off-by: Pau Ruiz Safont <pau.safont@vates.tech> (cherry picked from commit 0fdaf74)
This moves them outside of the try catch that destroys newly-cloned disks, but this is safe since these don't change the state of the host like the destroy vifs. This allows to simplify the type needed to be able to clean up the new VDIs in case of failure. Signed-off-by: Pau Ruiz Safont <pau.safont@vates.tech> (cherry picked from commit 37f15f8)
Previously in some parts of the revert, (rare) failures would not induce the deletion of newly cloned VDIs. Signed-off-by: Pau Ruiz Safont <pau.safont@vates.tech> (cherry picked from commit b996de8)
The VM creation function was added and the usage needs to be adapted to avoid a partial application. Signed-off-by: Pau Ruiz Safont <pau.safont@vates.tech>
This allows to switch on the more efficient interval format later. (QCOW always uses the new format) Signed-off-by: Andrii Sultanov <andriy.sultanov@vates.tech> (cherry picked from commit 1aa52ef)
This command returns a more efficient representation of allocated clusters (when compared to read_headers), utilizing a sparse interval format instead of returning every single allocated cluster. This is the more efficient option, decreasing the filesize and memory usage in vhd-tool, but it's currently under a feature flag, so it's added as a new command instead of replacing read_headers immediately. Cram test for read_headers is still passing, so this refactoring has preserved the legacy format. Signed-off-by: Andrii Sultanov <andriy.sultanov@vates.tech> (cherry picked from commit fa4f516)
Since the runtime feature flag vhd_legacy_blocks_format determines which block format is used to describe allocated VHD clusters, this requires duplicate parse_header_interval functions for VHD and QCOW. The right functions are selected in stream_vdi based on the feature flag. Signed-off-by: Andrii Sultanov <andriy.sultanov@vates.tech> (cherry picked from commit 5457512)
…er allocation Instead of using a set with every individual allocated cluster index as a member, use a sorted list of intervals to verify if cluster is allocated - this uses much less memory and directly follows from the JSON format qcow-stream-tool and vhd-tool output now. Signed-off-by: Andrii Sultanov <andriy.sultanov@vates.tech> (cherry picked from commit 1fc8ee7)
…_clusters nonzero_clusters no longer contain every single allocated cluster and instead are intervals of allocated clusters. Signed-off-by: Andrii Sultanov <andriy.sultanov@vates.tech> (cherry picked from commit a52b126)
Signed-off-by: Andrii Sultanov <andriy.sultanov@vates.tech> (cherry picked from commit f9db34b)
This proves much more reliable than code based on ocaml-qcow. Since qemu-img has a different format (with the needed information spread across two files resulting from calls to 'qemu-img info' and 'qemu-img map'), change the parsing code in vhd_qcow_parsing and qcow2-to-stdout. Signed-off-by: Andrii Sultanov <andriy.sultanov@vates.tech> (cherry picked from commit 3f6f6dd)
qemu-img is now used to determine allocated clusters, so this command is no longer needed. Signed-off-by: Andrii Sultanov <andriy.sultanov@vates.tech> (cherry picked from commit 829c018)
With input from changlei-li, minglumlu, and robhoes Signed-off-by: Sebastien Marie <semarie@kapouay.eu.org>
I would like to discuss the following design document before proposing the related implementation.
It is currently possible to accidentally pass through a PCI device backing the
boot drive, making the system unbootable and requiring manual intervention
(since dom0 will no longer be able to access the PCI device).
Fix this at least for the drive behind '/', refusing to pass through its PCI
device.
As an example, for 00:1f.2 SATA controller behind '/':
$ /usr/bin/findmnt -no source /
/dev/sda1
$ udevadm info -q path -n /dev/sda1
/devices/pci0000:00/0000:00:1f.2/ata5/host4/target4:0:0/4:0:0:0/block/sda/sda1
Disabling dom0 access before this commit:
$ xe pci-disable-dom0-access uuid=$UUID
disable_on_reboot
$ /opt/xensource/libexec/xen-cmdline --get-dom0 xen-pciback.hide
xen-pciback.hide=(0000:00:1f.2)
After:
$ xe pci-disable-dom0-access uuid=$UUID
Passing through a PCI device backing a boot disk is disallowed
device: /dev/sda1
$ /opt/xensource/libexec/xen-cmdline --get-dom0 xen-pciback.hide
<empty>
Signed-off-by: Andrii Sultanov <andriy.sultanov@vates.tech>
verification When a host joins a pool (pool.join_force), the process has two phases: 1. An unverified TLS connection is used to run pre-join checks and exchange host certificates. The joiner imports the pool bundle. 2. A verified TLS connection (verifyPeer=yes, SNI=pool) is opened using the freshly-generated pool bundle. Previously, any failure at Phase 2 surfaced as: INTERNAL_ERROR(Stunnel.Stunnel_verify_error( This error is opaque and gives no actionable information to the administrator. The idea is to improve error handling in order to obtain something more precise. Signed-off-by: Lucas RAVAGNIER <ravagnierlucas@gmail.com>
#7112) When a host joins a pool (pool.join_force), the process has two phases: 1. An unverified TLS connection is used to run pre-join checks and exchange host certificates. The joiner imports the pool bundle. 2. A verified TLS connection (verifyPeer=yes, SNI=pool) is opened using the freshly-generated pool bundle. Previously, any failure at Phase 2 surfaced as: INTERNAL_ERROR(Stunnel.Stunnel_verify_error( This error is opaque and gives no actionable information to the administrator. The idea is to improve error handling in order to obtain something more precise.
Use non-deprecated list operation instead of -a Signed-off-by: Mark Syms <mark.syms@citrix.com>
Signed-off-by: Mark Syms <mark.syms@citrix.com>
Also rename some volume methods that should be internal so that the invalid command handler works as expected. Signed-off-by: Mark Syms <mark.syms@citrix.com>
Signed-off-by: Ming Lu <ming.lu@cloud.com>
It is currently possible to accidentally pass through a PCI device
backing the boot drive, making the system unbootable and requiring
manual intervention (since dom0 will no longer be able to access the PCI
device).
Fix this at least for the drive behind '/', refusing to pass through its
PCI device.
As an example, for `00:1f.2` SATA controller behind '/':
$ /usr/bin/findmnt -no source /
/dev/sda1
$ udevadm info -q path -n /dev/sda1
/devices/pci0000:00/0000:00:1f.2/ata5/host4/target4:0:0/4:0:0:0/block/sda/sda1
Disabling dom0 access before this commit:
$ xe pci-disable-dom0-access uuid=$UUID
disable_on_reboot
$ /opt/xensource/libexec/xen-cmdline --get-dom0 xen-pciback.hide
xen-pciback.hide=(0000:00:1f.2)
After:
$ xe pci-disable-dom0-access uuid=$UUID
Passing through a PCI device backing a boot disk is disallowed
device: /dev/sda1
$ /opt/xensource/libexec/xen-cmdline --get-dom0 xen-pciback.hide
<empty>
Looks like this mechanism was used in the past, and only one vestigial check on VBD creation was used. It does not make sense to create a VBD associated with a task and immediately check whether it has leaked.
XAPI exposes a VIF.configure_ipv4/v6 message to instruct guest agents to
configure the VM's IP settings on the host's behalf.
This feature currently works by setting /local/domain/<domid>/xenserver/
device/vif/<N>/static-ip-setting/enabled to one of the following values:
enabled=0: None (unconfigured), so IP settings are decided by the VM
itself
enabled=1: Static, using the address and gateway values in the same key
From the modes above, there's no way to go from a static IP config back
to DHCP, and therefore, someone wanting to switch back to DHCP would
need to log into the VM and make the changes there.
Add a new VIF configuration mode that specifies enabled=2. This mode
instructs the guest to configure its VIF to use DHCP (on IPv4) or any
appropriate method to obtain an IP address automatically (on IPv6).
Signed-off-by: Tu Dinh <ngoc-tu.dinh@vates.tech>
XAPI exposes a `VIF.configure_ipv4/v6` message to instruct guest agents to configure the VM's IP settings on the host's behalf. This feature currently works by setting `/local/domain/<domid>/xenserver/device/vif/<N>/static-ip-setting/enabled` to one of the following values: - `enabled=0`: None (unconfigured), so IP settings are decided by the VM itself - `enabled=1`: Static, using the `address` and `gateway` values in the same key From the modes above, there's no way to go from a static IP config back to DHCP, and therefore, someone wanting to switch back to DHCP would need to log into the VM and make the changes there. Add the following new VIF configuration modes: - `enabled=2`: DHCP (IPv4) or autoconfigured (IPv6). The XS guest agent [already tolerates this value](https://github.com/xenserver/win-xenguestagent/blob/f4353ff3064d47493821f1c95a5ed46efdf59bf4/src/xenguestlib/FeatureStaticIpSetting.cs#L534) since a very long time, and from my testing with the XS 9.6.0 guest agent, is capable of reverting to DHCP if enabled=2 is set.
These changes add both unit-tests and quicktests to make sure that regressions introduced with VDI.revert will be visible as early as possible. In particular: - unit tests have been added to make sure adding the VDI_REVERT SR operation doesn't break important internal properties. - quicktests have been added to test behaviour for both Disks and CDs Changes have been introduced in the error path, now VDIs are properly destroyed in some situation where they were meant to be destroyed, but the code failed to do so, making it more consistent. This is preparation for the changes to make this proposal a reality: https://github.com/xapi-project/xen-api/blob/master/doc/content/design/snapshot-revert.md This is a port to the master branch from #7103 - There was only a single merge conflict regarding the addition of two libraries conflicting in a dune file, which had an easy resolution to take both into account - One function in the quicktests changed, and needed a change in the new tests, which was added as a separate commit
This is a forward-port of #6895 (with the exception of commits later reverted in #7030 and #7022). Changes to VHD code are gated behind a feature flag (with previous behaviour kept by default). XCP-ng has been running the new VHD and QCOW code for a while now with no issues. This PR needs to be merged before the corresponding xs-opam PR (xapi-project/xs-opam#768)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.