xcp-ng / xcp Goto Github PK

View Code? Open in Web Editor NEW

1.2K 81.0 72.0 9.04 MB

Entry point for issues and wiki. Also contains some scripts and sources.

Home Page: https://xcp-ng.org

Python 82.35% Shell 17.65%

xcp-ng xapi xenserver xcp virtualization xen-cloud-platform virtualization-platform xen-source citrix

xcp's Introduction

XCP-ng

Turnkey Open Source Virtualization Platform

XCP-ng: the user-friendly, high-performance virtualization solution, developed collaboratively for unrestricted features and open-source accessibility.

⚡️ Quick start

Download the ISO here, and install it on your own hardware.

📚 Documentation

The official documentation is available at https://docs.xcp-ng.org

🚀 Features

Powerful virtualization platform: run, snapshot, live migrate & grow any kind of workload/Operating system on top of XCP-ng, even containers!
Turnkey: no complicated setup, XCP-ng is a true appliance with everything pre-configured and ready to run your VMs!
Security: based on the Xen hypervisor technology, XCP-ng is one of the most secure virtualization platform on the market, both technologically and with a really serious security workflow.
Manageable at scale: there's many integrated ways to manage your XCP-ng host, both locally and remotely with a CLI, GUI and API. Xen Orchestra is the de facto administration & backup platform for it.
Fully Open Source: no paywalls or complicated licenses, all the features are free
Pro supported: want to run in production? XCP-ng is part of the Vates VMS stack that got you covered from the virtualization platform to the administration & backup tools.

📸 Screenshots

🧑‍🚀 Community

XCP-ng has a living community that you can join on our forum.

The project is open to contributions, bug reports and you can also host a mirror for XCP-ng.

xcp's People

Contributors

Stargazers

Watchers

xcp's Issues

Sources components to RPMs

This will use mock. We have to figure out how it works exactly

cryptosetup on dom0

Hi guys,

first of all thanks for this nice fork :)

XenServer has removed the cryptosetup package on 7.x image. But it it possible to add cryptosetup again into the dom0? We need this for encrypting USB storages .

thanks and best regards

Sascha

Unable to mount NFS ISO store or install supplemental pack

I've done a fresh install of XCP-ng on a HP DL 180 G7, all seems to work and I can fire up the XOA image. When I tried to add an NFS ISO storage, I got errors and in the /var/log/kern.log I am seeing :
Apr 4 21:26:44 nxnproc1 kernel: [ 3652.301148] hpsa 0000:05:00.0: added scsi 0:0:0:0: RAID HP P410i controller SSDSmartPathCap- En- Exp=1 qd=1024 Apr 4 21:26:44 nxnproc1 kernel: [ 3652.301506] hpsa 0000:05:00.0: scsi 0:0:0:0 addition failed, device not added.
This errors shows every time I try to add the NFS mount, but also happens when I try to install the Container supplemental pack.

Start thinking about repo requirements -- particularly building and signing

Not detecting disks

Hello,
I am trying to install XCP-NG on a HP Gen 8 with a B320i Raid Controller however it seems that it is not detecting the Hard Disk Drives.

Any help is appreciated, thanks!

PCI Pass-Through

Followed ths guide https://xenserver.org/blog/entry/pci-pass-through-on-xenserver-7-0.html but cannot get pci pass-through working. Is this a feature that is working or will be working. Thanks

Feature: "allow_multiple_vdi_attach" via UI

Hello,
nice project guys. I followed XO and Kickstarter since born.
I want suggest a feature in XCP-NG:

easier way to manage "multiwrite" vdi (e.g. like vSphere did).

Ref. http://www.ha-guru.com/sharing-virtual-disks-between-xenserver-xcp-vms/

It could be interesting for Enterprise-grade companies

XCP-ng 7.5

XenServer 7.5 is now available.

We need to both release a new ISO of XCP-ng and a package update for current installs

Updates

New ISO

embed the missing /etc/shadow file (@stormi) #35
update all the product versions (@stormi)
embed the new EMU manager
add xcp-ng-updater.rpm (@stormi)
Fix wording of the EXT vs LVM option for local SR (@stormi) #45
Allow update from XS 7.5
generate the ISO (@stormi)
upload it

Strange networking issue

Hi all,

I am using XCP-NG version 7.4. I am having a strange networking issue within my xcp-ng box. The hardware is an i3 with 16GB of ram and a realtek nic. I currently have 4 VMs running on this host, all in hvm mode, and all using the default "Pool-wide network associated with eth0" virtual NIC.

When running more then 1 VM at a time, and attempting to connect or work with these VMs over the network, the VMs seem to "compete" for use of the single physical NIC on the XCP-NG host. I can't run iperf simultaneously on two VMs at the same time (on the same physical host). Is this a normal behavior with VMs running in HVM mode? Is there something else I'm missing here? What information can I provide to help troubleshoot this issue?

Installer says thin-prov is optimized storage for XCP-ng, but it's wrong

It's a side effect of a change on the branding file where XenDesktop has been replaced by XCP-ng.

This is highly misleading and has the effect of using EXT instead of LVM for local SR.

XCP 7.4.1 release

Checklist

new ISO format that's Windows compatible @olivierlambert
Citrix signed Windows PV driver removal (#29) @johnelse 🔴
EMU manager package removal @olivierlambert 🔴
new xcp-featured daemon @johnelse
new package to remove trademarks in HTML file and add XO links, add XCP-ng RPM repo @johnelse
repo up to date @olivierlambert
new XCP-center binary embed
Re-word "enable thin provisioning for XenDesktop" in installer to remove trademark @olivierlambert
remove "this is the password used in xencenter" line in password window during installer @olivierlambert

Supplemental Packs (container management) incompatible

I tried installing v7.3 but fails on all my coreos vms. "Not compatible with this server version"
I know you guys have other stuff to prioiritise but is there intent to make these packs work at some point?

Also JFYI, XCP-ng guesttutilies installer for windows still showing Citrix branding.

Remove Citrix copyrighted material in ISO tools

Stuff is inside xenserver-pv-tools-7.24.0-1.noarch.rpm.

Inside this package, there is an ISO containing various files we must remove:

EULA
copyright.txt
AUTORUN.INF
Setup.exe
xenlegacy.exe
managementagent{x64/x86}.msi

Please add traceroute to XCP-NG in the repo and ISO

traceroute is very handy to find/troubleshoot networking issues would be nice to have it installed by default.

Unable to install XCP-NG

Hi i tried installing and it has been stuck on the "Preparing for installation..." screen on 45% for 25 minutes now i tried reboot and using a different hardrive still same results. am i doing something wrong?

Need to use Joliet long to build XCP-ng ISO if mounted on Windows

PXE booting into the installer works. I get stuck when trying to use remote storage (NFS and HTTP):

Problem With Location
Setup was unable to access the location you specified - please check and try again.

It seems the file names are wrong. From the web server logs (where it apparently fails on the first file):

"GET [[installation source]]/repodata/4549ebed7e162f6addd8c658f7e66d8ca1b0ad604c15f34b1389f65d1c5397e0-primary.xml.gz HTTP/1.1" 404 558 "-" "Python-urllib/2.7"

In the XCP-ng ISO the file name actually is

4549ebed7e162f6addd8c658f7e66d8ca1b0ad604c15f34b1389f65d1c5397e0

etc/shadow(-) is missing in install.img

During my installation tests i noticed that the default root console on tty2 is not logged in during installation.

The root cause is, that install.img is missing /etc/shadow (/etc/shadow-). Both are present
in original xenserver install.img.

I re-created install.img for my tests including both files and then a bash was available on tty2 again.

Can this please be fixed for next release?

XCP-ng 7.4.1 vulnerable to Spectre / Meltdown?

This is on a fresh XCP-ng 7.4.1 install, where I've ran yum update and installed the relevant firmware update from HPE, from https://support.hpe.com/hpsc/swd/public/detail?swItemId=MTX_7566cf97c0fa4a77bf6c8e16d3#tab2

Are there any plans to upgrade the kernel to a newer version that includes these mitigations?

I'm using this script to check for mitigation: https://raw.githubusercontent.com/speed47/spectre-meltdown-checker/master/spectre-meltdown-checker.sh

[root@core1h01 ~]# lsb_release -a
LSB Version:	:core-4.1-amd64:core-4.1-noarch
Distributor ID:	XCP-ng
Description:	XCP-ng release 7.4.0 (XCP-ng)
Release:	7.4.0
Codename:	XCP-ng
[root@core1h01 ~]# ./spectre-meltdown-checker.sh 
Spectre and Meltdown mitigation detection tool v0.37+

Checking for vulnerabilities on current system
Kernel is Linux 4.4.0+10 #1 SMP Mon Feb 19 10:31:57 UTC 2018 x86_64
CPU is Intel(R) Xeon(R) CPU           X5675  @ 3.07GHz

Hardware check
* Hardware support (CPU microcode) for mitigation techniques
  * Indirect Branch Restricted Speculation (IBRS)
    * SPEC_CTRL MSR is available:  YES 
    * CPU indicates IBRS capability:  YES  (SPEC_CTRL feature bit)
  * Indirect Branch Prediction Barrier (IBPB)
    * PRED_CMD MSR is available:  YES 
    * CPU indicates IBPB capability:  YES  (SPEC_CTRL feature bit)
  * Single Thread Indirect Branch Predictors (STIBP)
    * SPEC_CTRL MSR is available:  YES 
    * CPU indicates STIBP capability:  YES  (Intel STIBP feature bit)
  * Speculative Store Bypass Disable (SSBD)
    * CPU indicates SSBD capability:  NO 
  * Enhanced IBRS (IBRS_ALL)
    * CPU indicates ARCH_CAPABILITIES MSR availability:  NO 
    * ARCH_CAPABILITIES MSR advertises IBRS_ALL capability:  NO 
  * CPU explicitly indicates not being vulnerable to Meltdown (RDCL_NO):  NO 
  * CPU explicitly indicates not being vulnerable to Variant 4 (SSB_NO):  NO 
  * CPU microcode is known to cause stability problems:  NO  (model 0x2c family 0x6 stepping 0x2 ucode 0x1e cpuid 0x206c2)
* CPU vulnerability to the speculative execution attack variants
  * Vulnerable to Variant 1:  YES 
  * Vulnerable to Variant 2:  YES 
  * Vulnerable to Variant 3:  YES 
  * Vulnerable to Variant 3a:  YES 
  * Vulnerable to Variant 4:  YES 

CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Kernel has array_index_mask_nospec (x86):  NO 
* Kernel has the Red Hat/Ubuntu patch:  NO 
* Kernel has mask_nospec64 (arm):  NO 
* Checking count of LFENCE instructions following a jump in kernel...  NO  (only 4 jump-then-lfence instructions found, should be >= 30 (heuristic))
> STATUS:  VULNERABLE  (Kernel source needs to be patched to mitigate the vulnerability)

> How to fix: Your kernel is too old to have the mitigation for Variant 1, you should upgrade to a newer kernel. If you're using a Linux distro and didn't compile the kernel yourself, you should upgrade your distro to get a newer kernel.

CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigation 1
  * Kernel is compiled with IBRS support:  NO 
    * IBRS enabled and active:  UNKNOWN 
  * Kernel is compiled with IBPB support:  NO 
    * IBPB enabled and active:  NO 
* Mitigation 2
  * Kernel has branch predictor hardening (arm):  NO 
  * Kernel compiled with retpoline option:  NO 
> STATUS:  VULNERABLE  (IBRS+IBPB or retpoline+IBPB is needed to mitigate the vulnerability)

> How to fix: To mitigate this vulnerability, you need either IBRS + IBPB, both requiring hardware support from your CPU microcode in addition to kernel support, or a kernel compiled with retpoline and IBPB, with retpoline requiring a retpoline-aware compiler (re-run this script with -v to know if your version of gcc is retpoline-aware) and IBPB requiring hardware support from your CPU microcode. The retpoline + IBPB approach is generally preferred as the performance impact is lower. More information about how to enable the missing bits for those two possible mitigations on your system follow. You only need to take one of the two approaches.

> How to fix: Your kernel doesn't have IBPB support, so you need to either upgrade your kernel (if you're using a distro) or recompiling a more recent kernel.

> How to fix: Your kernel doesn't have IBRS support, so you need to either upgrade your kernel (if you're using a distro) or recompiling a more recent kernel.

CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Kernel supports Page Table Isolation (PTI):  NO 
  * PTI enabled and active:  NO 
  * Reduced performance impact of PTI:  NO  (PCID/INVPCID not supported, performance impact of PTI will be significant)
* Running as a Xen PV DomU:  NO 
> STATUS:  NOT VULNERABLE  (Xen Dom0s are safe and do not require PTI)

This host is a Xen Dom0. Please make sure that you are running your DomUs
in HVM, PVHVM or PVH mode to prevent any guest-to-host / host-to-guest attacks.

See https://blog.xenproject.org/2018/01/22/xen-project-spectre-meltdown-faq-jan-22-update/ and XSA-254 for details.

CVE-2018-3640 [rogue system register read] aka 'Variant 3a'
* CPU microcode mitigates the vulnerability:  NO 
> STATUS:  VULNERABLE  (an up-to-date CPU microcode is needed to mitigate this vulnerability)

> How to fix: The microcode of your CPU needs to be upgraded to mitigate this vulnerability. This is usually done at boot time by your kernel (the upgrade is not persistent across reboots which is why it's done at each boot). If you're using a distro, make sure you are up to date, as microcode updates are usually shipped alongside with the distro kernel. Availability of a microcode update for you CPU model depends on your CPU vendor. You can usually find out online if a microcode update is available for your CPU by searching for your CPUID (indicated in the Hardware Check section). The microcode update is enough, there is no additional OS, kernel or software change needed.

CVE-2018-3639 [speculative store bypass] aka 'Variant 4'
* Kernel supports speculation store bypass:  NO 
> STATUS:  VULNERABLE  (Neither your CPU nor your kernel support SSBD)

> How to fix: Both your CPU microcode and your kernel are lacking support for mitigation. If you're using a distro kernel, upgrade your distro to get the latest kernel available. Otherwise, recompile the kernel from recent-enough sources. The microcode of your CPU also needs to be upgraded. This is usually done at boot time by your kernel (the upgrade is not persistent across reboots which is why it's done at each boot). If you're using a distro, make sure you are up to date, as microcode updates are usually shipped alongside with the distro kernel. Availability of a microcode update for you CPU model depends on your CPU vendor. You can usually find out online if a microcode update is available for your CPU by searching for your CPUID (indicated in the Hardware Check section).

A false sense of security is worse than no security at all, see --disclaimer

xcp-ng 7.5.0 yum upgrade - missing symlink from xcp-featured - can't connect to anything

Disclaimer: I know it is experimental, but I wanted to have a try :)
After doing a 7.5.0 yum upgrade, server rebooted fine. SSH fine. VMs are up.
No connection on 443.
I tracked the issue down to v6d.service not running.
By inspecting the log, I found out that /opt/xensource/libexec/v6d is missing
systemd[11596]: Failed at step EXEC spawning /opt/xensource/libexec/v6d: No such file or directory

And indeed, it is missing after upgrade.

yum tells me that /opt/xensource/libexec/v6d is part of package xcp-featured-1.1.0-2.el7.centos.x86_64 : XCP-ng feature daemon

yum reinstall fixed it. It is actually a symlink though;
/opt/xensource/libexec/v6d -> /opt/xensource/libexec/xcp-featured

Something that went missing in the upgrade somehow, but that fixed for me with xe-toolstack-restart

xcp-ng.org is down

Feature: UEFI support for guest VM

XS doesn't officially support it yet. But XEN hypervisor has experimental support since version 4.4.
Lack of UEFI guest support makes xen almost a legacy hypervisor :(

XCP-ng 7.4.2

Working EMU manager removal (xenops issue)
Windows PV tools removed from guest tools ISO
working release package outside a upgrade process (using yum)
improve branding process

Windows PV tools

Update by stormi: if you arrived here from README.txt, what you are looking for is probably this: https://github.com/xcp-ng/xcp/wiki/Guest-Tools /end of update by stormi

We can't embed Citrix signed PV drivers. We need to get those from Xen project and document how to install them.

Those "free" drivers aren't signed. We'll probably need to signed them somehow.

You can download them here: https://www.xenproject.org/downloads/windows-pv-drivers/winpv-drivers-81/winpv-drivers-820.html

All packages needed to build XCP

We must get a list of every RPM needed to get from a CentOS to a XCP like.

Using XS RPMs

XS RPMs are available in the XS ISO install. The only package we need to build ourselves is XAPI in the end. We got them uploaded there: https://cloud.vates.fr/index.php/s/L01f4oWE2qajs3Q

The only notable exception would be XAPI, because we'll use a RPM based on a fork.

Alternative: "Plain" Xen?

Problem: packaging quality could lead to issues with the rest of the stack.

Package list

See https://wiki.centos.org/HowTos/Xen/Xen4QuickStart

It's pretty easy:

yum install centos-release-xen
yum update
yum install xen

Once you reboot, verify that xen is running with xl info

XAPI Toolstack

See issue #1 and #2 for requirements

Build XCP-ng-Server-SDK

There is the XenServer-7.4.0-SDK ... I wonder from what sources they build that, couldn't find a repo (https://github.com/xenserver) with relation to the SDK.

Has anyone the answer?

List of plugins, supplemental packs, you name it

Add a list on the XCP-ng website of Plugins, Extensions, etc.

Leaving xentools in dvd drive before upgrading to xcp-ng leaves vm unbootable.

As above.

Replicate:
Deploy vm on xenserver, mount xentools iso. Upgrade DOM0. DVD drive will be "" (nothing) and xcp will report it couldn't attach storage and not boot vm.

Changing DVD drive to will allow boot.

I acctually reported this on Xenserver 6.5 (or if it was 6.0?) so one could say it works as designed.

Build components from the sources

It works using xenserver-build-env and the right calls:

git clone git://github.com/xenserver/xenserver-build-env
cd xenserver-build-env
./build.sh
./run.py -p xapi --rm

# --- you are now inside the docker container ---

git clone https://github.com/xcp-ng/xen-api.git
cd xen-api
./configure
make

Same principle for another component, eg xcp-networkd:

./build.sh
./run.py -p xcp-networkd --rm

# --- you are now inside the docker container ---

git clone [email protected]:xcp-ng/xcp-networkd.git
cd xcp-networkd
make

Remove the /var/update folder during/after XS upgrade

This folder cause a vulnerability in XAPI. See https://xenbits.xen.org/xsa/advisory-271.html

Fresh XCP-ng install aren't affected and can't be affected in the future.

CentOS to XCP-ng

Using RPMs in XenServer ISO, we must be able to get a clean CentOS 7 to XCP. And to have a working environment (ie: XAPI running, can connect to XO or using xe)

fix wiki page about Ceph on XCP-ng 7.5

For wiki page: https://github.com/xcp-ng/xcp/wiki/Ceph-on-XCP-ng-7.5-or-later

To install qemu-dp also required 'base' repo of CentOS.
yum install qemu-dp --enablerepo="xcp-ng-extras_testing*,base"
It needs to install dependencies: librados2 and librbd1.

Debian based distro support

Some people asked for it. Sounds hard to achieve, but we'll explore this in Phase III

HA error with 7.5

already tested xcp 7.4 and 7.4.1 with no issues.

installed 7.5 from scratch and I cannot enable HA.
Tried with NFS and FC, also with GFS2 and LVM.

the log from /var/log/SMlog

Aug 14 12:07:20 xcp-ng-1 SM: [31960]     if self._deactivate_locked(sr_uuid, vdi_uuid, caching_params):
Aug 14 12:07:20 xcp-ng-1 SM: [31960]   File "/opt/xensource/sm/blktap2.py", line 83, in wrapper
Aug 14 12:07:20 xcp-ng-1 SM: [31960]     ret = op(self, *args)
Aug 14 12:07:20 xcp-ng-1 SM: [31960]   File "/opt/xensource/sm/blktap2.py", line 1666, in _deactivate_locked
Aug 14 12:07:20 xcp-ng-1 SM: [31960]     self._remove_tag(vdi_uuid)
Aug 14 12:07:20 xcp-ng-1 SM: [31960]   File "/opt/xensource/sm/blktap2.py", line 1452, in _remove_tag
Aug 14 12:07:20 xcp-ng-1 SM: [31960]     assert sm_config.has_key(host_key)
Aug 14 12:07:20 xcp-ng-1 SM: [31960]
Aug 14 12:07:20 xcp-ng-1 SM: [31960] lock: closed /var/lock/sm/b7b8b6a2-6326-4402-9f95-96135bb1d2f7/vdi
Aug 14 12:07:20 xcp-ng-1 SM: [31960] lock: closed /var/lock/sm/e6c74423-9152-b3b9-f503-efccde0e3edb/sr
Aug 14 12:08:51 xcp-ng-1 SM: [32437] Setting LVM_DEVICE to /dev/disk/by-scsid/3600000e00d00000000012a6b00000000
Aug 14 12:08:51 xcp-ng-1 SM: [32437] Setting LVM_DEVICE to /dev/disk/by-scsid/3600000e00d00000000012a6b00000000
Aug 14 12:08:51 xcp-ng-1 SM: [32437] lock: opening lock file /var/lock/sm/e6c74423-9152-b3b9-f503-efccde0e3edb/sr
Aug 14 12:08:51 xcp-ng-1 SM: [32437] LVMCache created for VG_XenStorage-e6c74423-9152-b3b9-f503-efccde0e3edb
Aug 14 12:08:51 xcp-ng-1 SM: [32437] ['/sbin/vgs', 'VG_XenStorage-e6c74423-9152-b3b9-f503-efccde0e3edb']
Aug 14 12:08:51 xcp-ng-1 SM: [32437]   pread SUCCESS
Aug 14 12:08:51 xcp-ng-1 SM: [32437] lock: acquired /var/lock/sm/e6c74423-9152-b3b9-f503-efccde0e3edb/sr
Aug 14 12:08:51 xcp-ng-1 SM: [32437] LVMCache: will initialize now
Aug 14 12:08:51 xcp-ng-1 SM: [32437] LVMCache: refreshing
Aug 14 12:08:51 xcp-ng-1 SM: [32437] ['/sbin/lvs', '--noheadings', '--units', 'b', '-o', '+lv_tags', '/dev/VG_XenStorage-e6c74423-9152-b3b9-f503-efccde0e3edb']
Aug 14 12:08:51 xcp-ng-1 SM: [32437]   pread SUCCESS
Aug 14 12:08:51 xcp-ng-1 SM: [32437] lock: released /var/lock/sm/e6c74423-9152-b3b9-f503-efccde0e3edb/sr
Aug 14 12:08:51 xcp-ng-1 SM: [32437] Entering _checkMetadataVolume
Aug 14 12:08:51 xcp-ng-1 SM: [32437] vdi_generate_config {'sr_uuid': 'e6c74423-9152-b3b9-f503-efccde0e3edb', 'subtask_of': 'OpaqueRef:5b5a6883-145d-404a-b9e3-e0715b227549', 'vdi_ref': 'OpaqueRef:94e45b2c-d99f-44e9-a4b5-e9660c99ecb4', 'vdi_on_boot': 'persist', 'args': [], 'vdi_location': 'ed1ae7c2-a5cb-4989-8bd2-7e351b77c835', 'host_ref': 'OpaqueRef:e4c37665-3b24-4b25-9da3-cf3567000e4b', 'session_ref': 'OpaqueRef:7f0ea971-e941-448f-a4a8-26af782c34a3', 'device_config': {'device': '/dev/disk/by-id/scsi-3600000e00d00000000012a6b00000000', 'SCSIid': '3600000e00d00000000012a6b00000000', 'SRmaster': 'true'}, 'command': 'vdi_generate_config', 'vdi_allow_caching': 'false', 'sr_ref': 'OpaqueRef:ddd6717d-987e-4618-9686-21af1f6bd7ff', 'vdi_uuid': 'ed1ae7c2-a5cb-4989-8bd2-7e351b77c835'}
Aug 14 12:08:51 xcp-ng-1 SM: [32437] LVHDoHBAVDI.generate_config
Aug 14 12:08:51 xcp-ng-1 SM: [32437] ['/sbin/lvdisplay', '/dev/VG_XenStorage-e6c74423-9152-b3b9-f503-efccde0e3edb/LV-ed1ae7c2-a5cb-4989-8bd2-7e351b77c835']
Aug 14 12:08:51 xcp-ng-1 SM: [32437]   pread SUCCESS
Aug 14 12:08:51 xcp-ng-1 SM: [32437] lock: closed /var/lock/sm/e6c74423-9152-b3b9-f503-efccde0e3edb/sr
Aug 14 12:08:52 xcp-ng-1 SM: [32462] Setting LVM_DEVICE to /dev/disk/by-scsid/3600000e00d00000000012a6b00000000
Aug 14 12:08:52 xcp-ng-1 SM: [32462] Setting LVM_DEVICE to /dev/disk/by-scsid/3600000e00d00000000012a6b00000000
Aug 14 12:08:52 xcp-ng-1 SM: [32462] Caught exception while looking up PBD for host  SR None: 'NoneType' object has no attribute 'xenapi'
Aug 14 12:08:52 xcp-ng-1 SM: [32462] lock: opening lock file /var/lock/sm/e6c74423-9152-b3b9-f503-efccde0e3edb/sr
Aug 14 12:08:52 xcp-ng-1 SM: [32462] LVMCache created for VG_XenStorage-e6c74423-9152-b3b9-f503-efccde0e3edb
Aug 14 12:08:52 xcp-ng-1 SM: [32462] ['/sbin/vgs', 'VG_XenStorage-e6c74423-9152-b3b9-f503-efccde0e3edb']
Aug 14 12:08:52 xcp-ng-1 SM: [32462]   pread SUCCESS
Aug 14 12:08:52 xcp-ng-1 SM: [32462] LVMCache: will initialize now
Aug 14 12:08:52 xcp-ng-1 SM: [32462] LVMCache: refreshing
Aug 14 12:08:52 xcp-ng-1 SM: [32462] ['/sbin/lvs', '--noheadings', '--units', 'b', '-o', '+lv_tags', '/dev/VG_XenStorage-e6c74423-9152-b3b9-f503-efccde0e3edb']
Aug 14 12:08:52 xcp-ng-1 SM: [32462]   pread SUCCESS
Aug 14 12:08:52 xcp-ng-1 SM: [32462] vdi_attach_from_config {'sr_uuid': 'e6c74423-9152-b3b9-f503-efccde0e3edb', 'device_config': {'device': '/dev/disk/by-id/scsi-3600000e00d00000000012a6b00000000', 'multipathing': 'false', 'SCSIid': '3600000e00d00000000012a6b00000000', 'SRmaster': 'true', 'multipathhandle': 'null'}, 'command': 'vdi_attach_from_config', 'vdi_uuid': 'ed1ae7c2-a5cb-4989-8bd2-7e351b77c835'}
Aug 14 12:08:52 xcp-ng-1 SM: [32462] LVHDoHBAVDI.attach_from_config
Aug 14 12:08:52 xcp-ng-1 SM: [32462] LVHDVDI.attach for ed1ae7c2-a5cb-4989-8bd2-7e351b77c835
Aug 14 12:08:52 xcp-ng-1 SM: [32462] lock: opening lock file /var/lock/sm/lvm-e6c74423-9152-b3b9-f503-efccde0e3edb/ed1ae7c2-a5cb-4989-8bd2-7e351b77c835
Aug 14 12:08:52 xcp-ng-1 SM: [32462] lock: acquired /var/lock/sm/lvm-e6c74423-9152-b3b9-f503-efccde0e3edb/ed1ae7c2-a5cb-4989-8bd2-7e351b77c835
Aug 14 12:08:52 xcp-ng-1 SM: [32462] lock: released /var/lock/sm/lvm-e6c74423-9152-b3b9-f503-efccde0e3edb/ed1ae7c2-a5cb-4989-8bd2-7e351b77c835
Aug 14 12:08:52 xcp-ng-1 SM: [32462] lock: closed /var/lock/sm/lvm-e6c74423-9152-b3b9-f503-efccde0e3edb/ed1ae7c2-a5cb-4989-8bd2-7e351b77c835
Aug 14 12:08:52 xcp-ng-1 SM: [32462] lock: opening lock file /var/lock/sm/lvm-e6c74423-9152-b3b9-f503-efccde0e3edb/ed1ae7c2-a5cb-4989-8bd2-7e351b77c835
Aug 14 12:08:52 xcp-ng-1 SM: [32462] lock: acquired /var/lock/sm/lvm-e6c74423-9152-b3b9-f503-efccde0e3edb/ed1ae7c2-a5cb-4989-8bd2-7e351b77c835
Aug 14 12:08:52 xcp-ng-1 SM: [32462] Refcount for lvm-e6c74423-9152-b3b9-f503-efccde0e3edb:ed1ae7c2-a5cb-4989-8bd2-7e351b77c835 (0, 0) + (0, 1) => (0, 1)
Aug 14 12:08:52 xcp-ng-1 SM: [32462] Refcount for lvm-e6c74423-9152-b3b9-f503-efccde0e3edb:ed1ae7c2-a5cb-4989-8bd2-7e351b77c835 set => (0, 1b)
Aug 14 12:08:52 xcp-ng-1 SM: [32462] ['/sbin/lvchange', '-ay', '/dev/VG_XenStorage-e6c74423-9152-b3b9-f503-efccde0e3edb/LV-ed1ae7c2-a5cb-4989-8bd2-7e351b77c835']
Aug 14 12:08:52 xcp-ng-1 SM: [32462]   pread SUCCESS
Aug 14 12:08:52 xcp-ng-1 SM: [32462] lock: released /var/lock/sm/lvm-e6c74423-9152-b3b9-f503-efccde0e3edb/ed1ae7c2-a5cb-4989-8bd2-7e351b77c835
Aug 14 12:08:52 xcp-ng-1 SM: [32462] lock: closed /var/lock/sm/lvm-e6c74423-9152-b3b9-f503-efccde0e3edb/ed1ae7c2-a5cb-4989-8bd2-7e351b77c835
Aug 14 12:08:52 xcp-ng-1 SM: [32462] lock: closed /var/lock/sm/e6c74423-9152-b3b9-f503-efccde0e3edb/sr
Aug 14 12:08:52 xcp-ng-1 SM: [32523] Setting LVM_DEVICE to /dev/disk/by-scsid/3600000e00d00000000012a6b00000000
Aug 14 12:08:52 xcp-ng-1 SM: [32523] Setting LVM_DEVICE to /dev/disk/by-scsid/3600000e00d00000000012a6b00000000
Aug 14 12:08:52 xcp-ng-1 SM: [32523] lock: opening lock file /var/lock/sm/e6c74423-9152-b3b9-f503-efccde0e3edb/sr
Aug 14 12:08:52 xcp-ng-1 SM: [32523] LVMCache created for VG_XenStorage-e6c74423-9152-b3b9-f503-efccde0e3edb
Aug 14 12:08:52 xcp-ng-1 SM: [32523] ['/sbin/vgs', 'VG_XenStorage-e6c74423-9152-b3b9-f503-efccde0e3edb']
Aug 14 12:08:52 xcp-ng-1 SM: [32523]   pread SUCCESS
Aug 14 12:08:52 xcp-ng-1 SM: [32523] lock: acquired /var/lock/sm/e6c74423-9152-b3b9-f503-efccde0e3edb/sr
Aug 14 12:08:52 xcp-ng-1 SM: [32523] LVMCache: will initialize now
Aug 14 12:08:52 xcp-ng-1 SM: [32523] LVMCache: refreshing
Aug 14 12:08:52 xcp-ng-1 SM: [32523] ['/sbin/lvs', '--noheadings', '--units', 'b', '-o', '+lv_tags', '/dev/VG_XenStorage-e6c74423-9152-b3b9-f503-efccde0e3edb']
Aug 14 12:08:52 xcp-ng-1 SM: [32523]   pread SUCCESS
Aug 14 12:08:52 xcp-ng-1 SM: [32523] lock: released /var/lock/sm/e6c74423-9152-b3b9-f503-efccde0e3edb/sr
Aug 14 12:08:52 xcp-ng-1 SM: [32523] Entering _checkMetadataVolume
Aug 14 12:08:52 xcp-ng-1 SM: [32523] vdi_generate_config {'sr_uuid': 'e6c74423-9152-b3b9-f503-efccde0e3edb', 'subtask_of': 'OpaqueRef:8d0fbda6-bf9c-47cc-a625-f4f2eb6af9b6', 'vdi_ref': 'OpaqueRef:b34971ea-0441-4266-8413-23a22ef5a226', 'vdi_on_boot': 'persist', 'args': [], 'vdi_location': 'b7b8b6a2-6326-4402-9f95-96135bb1d2f7', 'host_ref': 'OpaqueRef:e4c37665-3b24-4b25-9da3-cf3567000e4b', 'session_ref': 'OpaqueRef:e17028c1-a39d-4751-a809-84b2a25c6920', 'device_config': {'device': '/dev/disk/by-id/scsi-3600000e00d00000000012a6b00000000', 'SCSIid': '3600000e00d00000000012a6b00000000', 'SRmaster': 'true'}, 'command': 'vdi_generate_config', 'vdi_allow_caching': 'false', 'sr_ref': 'OpaqueRef:ddd6717d-987e-4618-9686-21af1f6bd7ff', 'vdi_uuid': 'b7b8b6a2-6326-4402-9f95-96135bb1d2f7'}
Aug 14 12:08:52 xcp-ng-1 SM: [32523] LVHDoHBAVDI.generate_config
Aug 14 12:08:52 xcp-ng-1 SM: [32523] ['/sbin/lvdisplay', '/dev/VG_XenStorage-e6c74423-9152-b3b9-f503-efccde0e3edb/LV-b7b8b6a2-6326-4402-9f95-96135bb1d2f7']
Aug 14 12:08:52 xcp-ng-1 SM: [32523]   pread SUCCESS
Aug 14 12:08:52 xcp-ng-1 SM: [32523] lock: closed /var/lock/sm/e6c74423-9152-b3b9-f503-efccde0e3edb/sr
Aug 14 12:08:53 xcp-ng-1 SM: [32553] Setting LVM_DEVICE to /dev/disk/by-scsid/3600000e00d00000000012a6b00000000
Aug 14 12:08:53 xcp-ng-1 SM: [32553] Setting LVM_DEVICE to /dev/disk/by-scsid/3600000e00d00000000012a6b00000000
Aug 14 12:08:53 xcp-ng-1 SM: [32553] Caught exception while looking up PBD for host  SR None: 'NoneType' object has no attribute 'xenapi'
Aug 14 12:08:53 xcp-ng-1 SM: [32553] lock: opening lock file /var/lock/sm/e6c74423-9152-b3b9-f503-efccde0e3edb/sr
Aug 14 12:08:53 xcp-ng-1 SM: [32553] LVMCache created for VG_XenStorage-e6c74423-9152-b3b9-f503-efccde0e3edb
Aug 14 12:08:53 xcp-ng-1 SM: [32553] ['/sbin/vgs', 'VG_XenStorage-e6c74423-9152-b3b9-f503-efccde0e3edb']
Aug 14 12:08:53 xcp-ng-1 SM: [32553]   pread SUCCESS
Aug 14 12:08:53 xcp-ng-1 SM: [32553] LVMCache: will initialize now
Aug 14 12:08:53 xcp-ng-1 SM: [32553] LVMCache: refreshing
Aug 14 12:08:53 xcp-ng-1 SM: [32553] ['/sbin/lvs', '--noheadings', '--units', 'b', '-o', '+lv_tags', '/dev/VG_XenStorage-e6c74423-9152-b3b9-f503-efccde0e3edb']
Aug 14 12:08:53 xcp-ng-1 SM: [32553]   pread SUCCESS
Aug 14 12:08:53 xcp-ng-1 SM: [32553] vdi_attach_from_config {'sr_uuid': 'e6c74423-9152-b3b9-f503-efccde0e3edb', 'device_config': {'device': '/dev/disk/by-id/scsi-3600000e00d00000000012a6b00000000', 'multipathing': 'false', 'SCSIid': '3600000e00d00000000012a6b00000000', 'SRmaster': 'true', 'multipathhandle': 'null'}, 'command': 'vdi_attach_from_config', 'vdi_uuid': 'b7b8b6a2-6326-4402-9f95-96135bb1d2f7'}
Aug 14 12:08:53 xcp-ng-1 SM: [32553] LVHDoHBAVDI.attach_from_config
Aug 14 12:08:53 xcp-ng-1 SM: [32553] LVHDVDI.attach for b7b8b6a2-6326-4402-9f95-96135bb1d2f7
Aug 14 12:08:53 xcp-ng-1 SM: [32553] lock: opening lock file /var/lock/sm/lvm-e6c74423-9152-b3b9-f503-efccde0e3edb/b7b8b6a2-6326-4402-9f95-96135bb1d2f7
Aug 14 12:08:53 xcp-ng-1 SM: [32553] lock: acquired /var/lock/sm/lvm-e6c74423-9152-b3b9-f503-efccde0e3edb/b7b8b6a2-6326-4402-9f95-96135bb1d2f7
Aug 14 12:08:53 xcp-ng-1 SM: [32553] lock: released /var/lock/sm/lvm-e6c74423-9152-b3b9-f503-efccde0e3edb/b7b8b6a2-6326-4402-9f95-96135bb1d2f7
Aug 14 12:08:53 xcp-ng-1 SM: [32553] lock: closed /var/lock/sm/lvm-e6c74423-9152-b3b9-f503-efccde0e3edb/b7b8b6a2-6326-4402-9f95-96135bb1d2f7
Aug 14 12:08:53 xcp-ng-1 SM: [32553] lock: opening lock file /var/lock/sm/lvm-e6c74423-9152-b3b9-f503-efccde0e3edb/b7b8b6a2-6326-4402-9f95-96135bb1d2f7
Aug 14 12:08:53 xcp-ng-1 SM: [32553] lock: acquired /var/lock/sm/lvm-e6c74423-9152-b3b9-f503-efccde0e3edb/b7b8b6a2-6326-4402-9f95-96135bb1d2f7
Aug 14 12:08:53 xcp-ng-1 SM: [32553] Refcount for lvm-e6c74423-9152-b3b9-f503-efccde0e3edb:b7b8b6a2-6326-4402-9f95-96135bb1d2f7 (0, 0) + (0, 1) => (0, 1)
Aug 14 12:08:53 xcp-ng-1 SM: [32553] Refcount for lvm-e6c74423-9152-b3b9-f503-efccde0e3edb:b7b8b6a2-6326-4402-9f95-96135bb1d2f7 set => (0, 1b)
Aug 14 12:08:53 xcp-ng-1 SM: [32553] ['/sbin/lvchange', '-ay', '/dev/VG_XenStorage-e6c74423-9152-b3b9-f503-efccde0e3edb/LV-b7b8b6a2-6326-4402-9f95-96135bb1d2f7']
Aug 14 12:08:53 xcp-ng-1 SM: [32553]   pread SUCCESS
Aug 14 12:08:53 xcp-ng-1 SM: [32553] lock: released /var/lock/sm/lvm-e6c74423-9152-b3b9-f503-efccde0e3edb/b7b8b6a2-6326-4402-9f95-96135bb1d2f7
Aug 14 12:08:53 xcp-ng-1 SM: [32553] lock: closed /var/lock/sm/lvm-e6c74423-9152-b3b9-f503-efccde0e3edb/b7b8b6a2-6326-4402-9f95-96135bb1d2f7
Aug 14 12:08:53 xcp-ng-1 SM: [32553] lock: closed /var/lock/sm/e6c74423-9152-b3b9-f503-efccde0e3edb/sr
Aug 14 12:09:02 xcp-ng-1 SM: [32739] Setting LVM_DEVICE to /dev/disk/by-scsid/3600000e00d00000000012a6b00000000
Aug 14 12:09:02 xcp-ng-1 SM: [32739] Setting LVM_DEVICE to /dev/disk/by-scsid/3600000e00d00000000012a6b00000000
Aug 14 12:09:02 xcp-ng-1 SM: [32739] lock: opening lock file /var/lock/sm/e6c74423-9152-b3b9-f503-efccde0e3edb/sr
Aug 14 12:09:02 xcp-ng-1 SM: [32739] LVMCache created for VG_XenStorage-e6c74423-9152-b3b9-f503-efccde0e3edb
Aug 14 12:09:02 xcp-ng-1 SM: [32739] ['/sbin/vgs', 'VG_XenStorage-e6c74423-9152-b3b9-f503-efccde0e3edb']
Aug 14 12:09:02 xcp-ng-1 SM: [32739]   pread SUCCESS
Aug 14 12:09:02 xcp-ng-1 SM: [32739] Entering _checkMetadataVolume
Aug 14 12:09:02 xcp-ng-1 SM: [32739] LVMCache: will initialize now
Aug 14 12:09:02 xcp-ng-1 SM: [32739] LVMCache: refreshing
Aug 14 12:09:02 xcp-ng-1 SM: [32739] ['/sbin/lvs', '--noheadings', '--units', 'b', '-o', '+lv_tags', '/dev/VG_XenStorage-e6c74423-9152-b3b9-f503-efccde0e3edb']
Aug 14 12:09:02 xcp-ng-1 SM: [32739]   pread SUCCESS
Aug 14 12:09:02 xcp-ng-1 SM: [32739] vdi_deactivate {'sr_uuid': 'e6c74423-9152-b3b9-f503-efccde0e3edb', 'subtask_of': 'OpaqueRef:57f4932a-adc1-421c-b94e-0af161d6cc3b', 'vdi_ref': 'OpaqueRef:94e45b2c-d99f-44e9-a4b5-e9660c99ecb4', 'vdi_on_boot': 'persist', 'args': [], 'vdi_location': 'ed1ae7c2-a5cb-4989-8bd2-7e351b77c835', 'host_ref': 'OpaqueRef:e4c37665-3b24-4b25-9da3-cf3567000e4b', 'session_ref': 'OpaqueRef:4163f1d4-23b4-4bfb-b381-8fa437e66ce8', 'device_config': {'device': '/dev/disk/by-id/scsi-3600000e00d00000000012a6b00000000', 'SCSIid': '3600000e00d00000000012a6b00000000', 'SRmaster': 'true'}, 'command': 'vdi_deactivate', 'vdi_allow_caching': 'false', 'sr_ref': 'OpaqueRef:ddd6717d-987e-4618-9686-21af1f6bd7ff', 'vdi_uuid': 'ed1ae7c2-a5cb-4989-8bd2-7e351b77c835'}
Aug 14 12:09:02 xcp-ng-1 SM: [32739] lock: opening lock file /var/lock/sm/ed1ae7c2-a5cb-4989-8bd2-7e351b77c835/vdi
Aug 14 12:09:02 xcp-ng-1 SM: [32739] blktap2.deactivate
Aug 14 12:09:02 xcp-ng-1 SM: [32739] lock: acquired /var/lock/sm/ed1ae7c2-a5cb-4989-8bd2-7e351b77c835/vdi
Aug 14 12:09:02 xcp-ng-1 SM: [32739] Backend path /dev/sm/backend/e6c74423-9152-b3b9-f503-efccde0e3edb/ed1ae7c2-a5cb-4989-8bd2-7e351b77c835 does not exist
Aug 14 12:09:02 xcp-ng-1 SM: [32739] LVHDVDI.detach for ed1ae7c2-a5cb-4989-8bd2-7e351b77c835
Aug 14 12:09:02 xcp-ng-1 SM: [32739] lock: opening lock file /var/lock/sm/lvm-e6c74423-9152-b3b9-f503-efccde0e3edb/ed1ae7c2-a5cb-4989-8bd2-7e351b77c835
Aug 14 12:09:02 xcp-ng-1 SM: [32739] lock: acquired /var/lock/sm/lvm-e6c74423-9152-b3b9-f503-efccde0e3edb/ed1ae7c2-a5cb-4989-8bd2-7e351b77c835
Aug 14 12:09:02 xcp-ng-1 SM: [32739] lock: released /var/lock/sm/lvm-e6c74423-9152-b3b9-f503-efccde0e3edb/ed1ae7c2-a5cb-4989-8bd2-7e351b77c835
Aug 14 12:09:02 xcp-ng-1 SM: [32739] lock: closed /var/lock/sm/lvm-e6c74423-9152-b3b9-f503-efccde0e3edb/ed1ae7c2-a5cb-4989-8bd2-7e351b77c835
Aug 14 12:09:02 xcp-ng-1 SM: [32739] lock: opening lock file /var/lock/sm/lvm-e6c74423-9152-b3b9-f503-efccde0e3edb/ed1ae7c2-a5cb-4989-8bd2-7e351b77c835
Aug 14 12:09:02 xcp-ng-1 SM: [32739] lock: acquired /var/lock/sm/lvm-e6c74423-9152-b3b9-f503-efccde0e3edb/ed1ae7c2-a5cb-4989-8bd2-7e351b77c835
Aug 14 12:09:02 xcp-ng-1 SM: [32739] Refcount for lvm-e6c74423-9152-b3b9-f503-efccde0e3edb:ed1ae7c2-a5cb-4989-8bd2-7e351b77c835 (0, 1) + (0, -1) => (0, 0)
Aug 14 12:09:02 xcp-ng-1 SM: [32739] Refcount for lvm-e6c74423-9152-b3b9-f503-efccde0e3edb:ed1ae7c2-a5cb-4989-8bd2-7e351b77c835 set => (0, 0b)
Aug 14 12:09:02 xcp-ng-1 SM: [32739] ['/sbin/lvchange', '-an', '/dev/VG_XenStorage-e6c74423-9152-b3b9-f503-efccde0e3edb/LV-ed1ae7c2-a5cb-4989-8bd2-7e351b77c835']
Aug 14 12:09:02 xcp-ng-1 SM: [32739]   pread SUCCESS
Aug 14 12:09:02 xcp-ng-1 SM: [32739] ['/sbin/dmsetup', 'status', 'VG_XenStorage--e6c74423--9152--b3b9--f503--efccde0e3edb-LV--ed1ae7c2--a5cb--4989--8bd2--7e351b77c835']
Aug 14 12:09:02 xcp-ng-1 SM: [32739]   pread SUCCESS
Aug 14 12:09:02 xcp-ng-1 SM: [32739] lock: released /var/lock/sm/lvm-e6c74423-9152-b3b9-f503-efccde0e3edb/ed1ae7c2-a5cb-4989-8bd2-7e351b77c835
Aug 14 12:09:02 xcp-ng-1 SM: [32739] lock: closed /var/lock/sm/lvm-e6c74423-9152-b3b9-f503-efccde0e3edb/ed1ae7c2-a5cb-4989-8bd2-7e351b77c835
Aug 14 12:09:02 xcp-ng-1 SM: [32739] ***** BLKTAP2:<function _deactivate_locked at 0x1356500>: EXCEPTION <type 'exceptions.AssertionError'>,
Aug 14 12:09:02 xcp-ng-1 SM: [32739]   File "/opt/xensource/sm/blktap2.py", line 83, in wrapper
Aug 14 12:09:02 xcp-ng-1 SM: [32739]     ret = op(self, *args)
Aug 14 12:09:02 xcp-ng-1 SM: [32739]   File "/opt/xensource/sm/blktap2.py", line 1666, in _deactivate_locked
Aug 14 12:09:02 xcp-ng-1 SM: [32739]     self._remove_tag(vdi_uuid)
Aug 14 12:09:02 xcp-ng-1 SM: [32739]   File "/opt/xensource/sm/blktap2.py", line 1452, in _remove_tag
Aug 14 12:09:02 xcp-ng-1 SM: [32739]     assert sm_config.has_key(host_key)
Aug 14 12:09:02 xcp-ng-1 SM: [32739]
Aug 14 12:09:02 xcp-ng-1 SM: [32739] lock: released /var/lock/sm/ed1ae7c2-a5cb-4989-8bd2-7e351b77c835/vdi
Aug 14 12:09:02 xcp-ng-1 SM: [32739] ***** generic exception: vdi_deactivate: EXCEPTION <type 'exceptions.AssertionError'>,
Aug 14 12:09:02 xcp-ng-1 SM: [32739]   File "/opt/xensource/sm/SRCommand.py", line 110, in run
Aug 14 12:09:02 xcp-ng-1 SM: [32739]     return self._run_locked(sr)
Aug 14 12:09:02 xcp-ng-1 SM: [32739]   File "/opt/xensource/sm/SRCommand.py", line 159, in _run_locked
Aug 14 12:09:02 xcp-ng-1 SM: [32739]     rv = self._run(sr, target)
Aug 14 12:09:02 xcp-ng-1 SM: [32739]   File "/opt/xensource/sm/SRCommand.py", line 274, in _run
Aug 14 12:09:02 xcp-ng-1 SM: [32739]     caching_params)
Aug 14 12:09:02 xcp-ng-1 SM: [32739]   File "/opt/xensource/sm/blktap2.py", line 1647, in deactivate
Aug 14 12:09:02 xcp-ng-1 SM: [32739]     if self._deactivate_locked(sr_uuid, vdi_uuid, caching_params):
Aug 14 12:09:02 xcp-ng-1 SM: [32739]   File "/opt/xensource/sm/blktap2.py", line 83, in wrapper
Aug 14 12:09:02 xcp-ng-1 SM: [32739]     ret = op(self, *args)
Aug 14 12:09:02 xcp-ng-1 SM: [32739]   File "/opt/xensource/sm/blktap2.py", line 1666, in _deactivate_locked
Aug 14 12:09:02 xcp-ng-1 SM: [32739]     self._remove_tag(vdi_uuid)
Aug 14 12:09:02 xcp-ng-1 SM: [32739]   File "/opt/xensource/sm/blktap2.py", line 1452, in _remove_tag
Aug 14 12:09:02 xcp-ng-1 SM: [32739]     assert sm_config.has_key(host_key)
Aug 14 12:09:02 xcp-ng-1 SM: [32739]
Aug 14 12:09:02 xcp-ng-1 SM: [32739] ***** LVHD over FC: EXCEPTION <type 'exceptions.AssertionError'>,
Aug 14 12:09:02 xcp-ng-1 SM: [32739]   File "/opt/xensource/sm/SRCommand.py", line 372, in run
Aug 14 12:09:02 xcp-ng-1 SM: [32739]     ret = cmd.run(sr)
Aug 14 12:09:02 xcp-ng-1 SM: [32739]   File "/opt/xensource/sm/SRCommand.py", line 110, in run
Aug 14 12:09:02 xcp-ng-1 SM: [32739]     return self._run_locked(sr)
Aug 14 12:09:02 xcp-ng-1 SM: [32739]   File "/opt/xensource/sm/SRCommand.py", line 159, in _run_locked
Aug 14 12:09:02 xcp-ng-1 SM: [32739]     rv = self._run(sr, target)
Aug 14 12:09:02 xcp-ng-1 SM: [32739]   File "/opt/xensource/sm/SRCommand.py", line 274, in _run
Aug 14 12:09:02 xcp-ng-1 SM: [32739]     caching_params)
Aug 14 12:09:02 xcp-ng-1 SM: [32739]   File "/opt/xensource/sm/blktap2.py", line 1647, in deactivate
Aug 14 12:09:02 xcp-ng-1 SM: [32739]     if self._deactivate_locked(sr_uuid, vdi_uuid, caching_params):
Aug 14 12:09:02 xcp-ng-1 SM: [32739]   File "/opt/xensource/sm/blktap2.py", line 83, in wrapper
Aug 14 12:09:02 xcp-ng-1 SM: [32739]     ret = op(self, *args)
Aug 14 12:09:02 xcp-ng-1 SM: [32739]   File "/opt/xensource/sm/blktap2.py", line 1666, in _deactivate_locked
Aug 14 12:09:02 xcp-ng-1 SM: [32739]     self._remove_tag(vdi_uuid)
Aug 14 12:09:02 xcp-ng-1 SM: [32739]   File "/opt/xensource/sm/blktap2.py", line 1452, in _remove_tag
Aug 14 12:09:02 xcp-ng-1 SM: [32739]     assert sm_config.has_key(host_key)
Aug 14 12:09:02 xcp-ng-1 SM: [32739]
Aug 14 12:09:02 xcp-ng-1 SM: [32739] lock: closed /var/lock/sm/ed1ae7c2-a5cb-4989-8bd2-7e351b77c835/vdi
Aug 14 12:09:02 xcp-ng-1 SM: [32739] lock: closed /var/lock/sm/e6c74423-9152-b3b9-f503-efccde0e3edb/sr
Aug 14 12:09:03 xcp-ng-1 SM: [330] Setting LVM_DEVICE to /dev/disk/by-scsid/3600000e00d00000000012a6b00000000
Aug 14 12:09:03 xcp-ng-1 SM: [330] Setting LVM_DEVICE to /dev/disk/by-scsid/3600000e00d00000000012a6b00000000
Aug 14 12:09:03 xcp-ng-1 SM: [330] lock: opening lock file /var/lock/sm/e6c74423-9152-b3b9-f503-efccde0e3edb/sr
Aug 14 12:09:03 xcp-ng-1 SM: [330] LVMCache created for VG_XenStorage-e6c74423-9152-b3b9-f503-efccde0e3edb
Aug 14 12:09:03 xcp-ng-1 SM: [330] ['/sbin/vgs', 'VG_XenStorage-e6c74423-9152-b3b9-f503-efccde0e3edb']
Aug 14 12:09:03 xcp-ng-1 SM: [330]   pread SUCCESS
Aug 14 12:09:03 xcp-ng-1 SM: [330] Entering _checkMetadataVolume
Aug 14 12:09:03 xcp-ng-1 SM: [330] LVMCache: will initialize now
Aug 14 12:09:03 xcp-ng-1 SM: [330] LVMCache: refreshing
Aug 14 12:09:03 xcp-ng-1 SM: [330] ['/sbin/lvs', '--noheadings', '--units', 'b', '-o', '+lv_tags', '/dev/VG_XenStorage-e6c74423-9152-b3b9-f503-efccde0e3edb']
Aug 14 12:09:03 xcp-ng-1 SM: [330]   pread SUCCESS
Aug 14 12:09:03 xcp-ng-1 SM: [330] vdi_deactivate {'sr_uuid': 'e6c74423-9152-b3b9-f503-efccde0e3edb', 'subtask_of': 'OpaqueRef:57f4932a-adc1-421c-b94e-0af161d6cc3b', 'vdi_ref': 'OpaqueRef:b34971ea-0441-4266-8413-23a22ef5a226', 'vdi_on_boot': 'persist', 'args': [], 'vdi_location': 'b7b8b6a2-6326-4402-9f95-96135bb1d2f7', 'host_ref': 'OpaqueRef:e4c37665-3b24-4b25-9da3-cf3567000e4b', 'session_ref': 'OpaqueRef:2561aac2-7579-4ad7-8e9e-232bd6b64efa', 'device_config': {'device': '/dev/disk/by-id/scsi-3600000e00d00000000012a6b00000000', 'SCSIid': '3600000e00d00000000012a6b00000000', 'SRmaster': 'true'}, 'command': 'vdi_deactivate', 'vdi_allow_caching': 'false', 'sr_ref': 'OpaqueRef:ddd6717d-987e-4618-9686-21af1f6bd7ff', 'vdi_uuid': 'b7b8b6a2-6326-4402-9f95-96135bb1d2f7'}
Aug 14 12:09:03 xcp-ng-1 SM: [330] lock: opening lock file /var/lock/sm/b7b8b6a2-6326-4402-9f95-96135bb1d2f7/vdi
Aug 14 12:09:03 xcp-ng-1 SM: [330] blktap2.deactivate
Aug 14 12:09:03 xcp-ng-1 SM: [330] lock: acquired /var/lock/sm/b7b8b6a2-6326-4402-9f95-96135bb1d2f7/vdi
Aug 14 12:09:03 xcp-ng-1 SM: [330] Backend path /dev/sm/backend/e6c74423-9152-b3b9-f503-efccde0e3edb/b7b8b6a2-6326-4402-9f95-96135bb1d2f7 does not exist
Aug 14 12:09:03 xcp-ng-1 SM: [330] LVHDVDI.detach for b7b8b6a2-6326-4402-9f95-96135bb1d2f7
Aug 14 12:09:03 xcp-ng-1 SM: [330] lock: opening lock file /var/lock/sm/lvm-e6c74423-9152-b3b9-f503-efccde0e3edb/b7b8b6a2-6326-4402-9f95-96135bb1d2f7
Aug 14 12:09:03 xcp-ng-1 SM: [330] lock: acquired /var/lock/sm/lvm-e6c74423-9152-b3b9-f503-efccde0e3edb/b7b8b6a2-6326-4402-9f95-96135bb1d2f7
Aug 14 12:09:03 xcp-ng-1 SM: [330] lock: released /var/lock/sm/lvm-e6c74423-9152-b3b9-f503-efccde0e3edb/b7b8b6a2-6326-4402-9f95-96135bb1d2f7
Aug 14 12:09:03 xcp-ng-1 SM: [330] lock: closed /var/lock/sm/lvm-e6c74423-9152-b3b9-f503-efccde0e3edb/b7b8b6a2-6326-4402-9f95-96135bb1d2f7
Aug 14 12:09:03 xcp-ng-1 SM: [330] lock: opening lock file /var/lock/sm/lvm-e6c74423-9152-b3b9-f503-efccde0e3edb/b7b8b6a2-6326-4402-9f95-96135bb1d2f7
Aug 14 12:09:03 xcp-ng-1 SM: [330] lock: acquired /var/lock/sm/lvm-e6c74423-9152-b3b9-f503-efccde0e3edb/b7b8b6a2-6326-4402-9f95-96135bb1d2f7
Aug 14 12:09:03 xcp-ng-1 SM: [330] Refcount for lvm-e6c74423-9152-b3b9-f503-efccde0e3edb:b7b8b6a2-6326-4402-9f95-96135bb1d2f7 (0, 1) + (0, -1) => (0, 0)
Aug 14 12:09:03 xcp-ng-1 SM: [330] Refcount for lvm-e6c74423-9152-b3b9-f503-efccde0e3edb:b7b8b6a2-6326-4402-9f95-96135bb1d2f7 set => (0, 0b)
Aug 14 12:09:03 xcp-ng-1 SM: [330] ['/sbin/lvchange', '-an', '/dev/VG_XenStorage-e6c74423-9152-b3b9-f503-efccde0e3edb/LV-b7b8b6a2-6326-4402-9f95-96135bb1d2f7']
Aug 14 12:09:03 xcp-ng-1 SM: [330]   pread SUCCESS
Aug 14 12:09:03 xcp-ng-1 SM: [330] ['/sbin/dmsetup', 'status', 'VG_XenStorage--e6c74423--9152--b3b9--f503--efccde0e3edb-LV--b7b8b6a2--6326--4402--9f95--96135bb1d2f7']
Aug 14 12:09:03 xcp-ng-1 SM: [330]   pread SUCCESS
Aug 14 12:09:03 xcp-ng-1 SM: [330] lock: released /var/lock/sm/lvm-e6c74423-9152-b3b9-f503-efccde0e3edb/b7b8b6a2-6326-4402-9f95-96135bb1d2f7
Aug 14 12:09:03 xcp-ng-1 SM: [330] lock: closed /var/lock/sm/lvm-e6c74423-9152-b3b9-f503-efccde0e3edb/b7b8b6a2-6326-4402-9f95-96135bb1d2f7
Aug 14 12:09:03 xcp-ng-1 SM: [330] ***** BLKTAP2:<function _deactivate_locked at 0x16cc500>: EXCEPTION <type 'exceptions.AssertionError'>,
Aug 14 12:09:03 xcp-ng-1 SM: [330]   File "/opt/xensource/sm/blktap2.py", line 83, in wrapper
Aug 14 12:09:03 xcp-ng-1 SM: [330]     ret = op(self, *args)
Aug 14 12:09:03 xcp-ng-1 SM: [330]   File "/opt/xensource/sm/blktap2.py", line 1666, in _deactivate_locked
Aug 14 12:09:03 xcp-ng-1 SM: [330]     self._remove_tag(vdi_uuid)
Aug 14 12:09:03 xcp-ng-1 SM: [330]   File "/opt/xensource/sm/blktap2.py", line 1452, in _remove_tag
Aug 14 12:09:03 xcp-ng-1 SM: [330]     assert sm_config.has_key(host_key)
Aug 14 12:09:03 xcp-ng-1 SM: [330]
Aug 14 12:09:03 xcp-ng-1 SM: [330] lock: released /var/lock/sm/b7b8b6a2-6326-4402-9f95-96135bb1d2f7/vdi
Aug 14 12:09:03 xcp-ng-1 SM: [330] ***** generic exception: vdi_deactivate: EXCEPTION <type 'exceptions.AssertionError'>,
Aug 14 12:09:03 xcp-ng-1 SM: [330]   File "/opt/xensource/sm/SRCommand.py", line 110, in run
Aug 14 12:09:03 xcp-ng-1 SM: [330]     return self._run_locked(sr)
Aug 14 12:09:03 xcp-ng-1 SM: [330]   File "/opt/xensource/sm/SRCommand.py", line 159, in _run_locked
Aug 14 12:09:03 xcp-ng-1 SM: [330]     rv = self._run(sr, target)
Aug 14 12:09:03 xcp-ng-1 SM: [330]   File "/opt/xensource/sm/SRCommand.py", line 274, in _run
Aug 14 12:09:03 xcp-ng-1 SM: [330]     caching_params)
Aug 14 12:09:03 xcp-ng-1 SM: [330]   File "/opt/xensource/sm/blktap2.py", line 1647, in deactivate
Aug 14 12:09:03 xcp-ng-1 SM: [330]     if self._deactivate_locked(sr_uuid, vdi_uuid, caching_params):
Aug 14 12:09:03 xcp-ng-1 SM: [330]   File "/opt/xensource/sm/blktap2.py", line 83, in wrapper
Aug 14 12:09:03 xcp-ng-1 SM: [330]     ret = op(self, *args)
Aug 14 12:09:03 xcp-ng-1 SM: [330]   File "/opt/xensource/sm/blktap2.py", line 1666, in _deactivate_locked
Aug 14 12:09:03 xcp-ng-1 SM: [330]     self._remove_tag(vdi_uuid)
Aug 14 12:09:03 xcp-ng-1 SM: [330]   File "/opt/xensource/sm/blktap2.py", line 1452, in _remove_tag
Aug 14 12:09:03 xcp-ng-1 SM: [330]     assert sm_config.has_key(host_key)
Aug 14 12:09:03 xcp-ng-1 SM: [330]
Aug 14 12:09:03 xcp-ng-1 SM: [330] ***** LVHD over FC: EXCEPTION <type 'exceptions.AssertionError'>,
Aug 14 12:09:03 xcp-ng-1 SM: [330]   File "/opt/xensource/sm/SRCommand.py", line 372, in run
Aug 14 12:09:03 xcp-ng-1 SM: [330]     ret = cmd.run(sr)
Aug 14 12:09:03 xcp-ng-1 SM: [330]   File "/opt/xensource/sm/SRCommand.py", line 110, in run
Aug 14 12:09:03 xcp-ng-1 SM: [330]     return self._run_locked(sr)
Aug 14 12:09:03 xcp-ng-1 SM: [330]   File "/opt/xensource/sm/SRCommand.py", line 159, in _run_locked
Aug 14 12:09:03 xcp-ng-1 SM: [330]     rv = self._run(sr, target)
Aug 14 12:09:03 xcp-ng-1 SM: [330]   File "/opt/xensource/sm/SRCommand.py", line 274, in _run
Aug 14 12:09:03 xcp-ng-1 SM: [330]     caching_params)
Aug 14 12:09:03 xcp-ng-1 SM: [330]   File "/opt/xensource/sm/blktap2.py", line 1647, in deactivate
Aug 14 12:09:03 xcp-ng-1 SM: [330]     if self._deactivate_locked(sr_uuid, vdi_uuid, caching_params):
Aug 14 12:09:03 xcp-ng-1 SM: [330]   File "/opt/xensource/sm/blktap2.py", line 83, in wrapper
Aug 14 12:09:03 xcp-ng-1 SM: [330]     ret = op(self, *args)
Aug 14 12:09:03 xcp-ng-1 SM: [330]   File "/opt/xensource/sm/blktap2.py", line 1666, in _deactivate_locked
Aug 14 12:09:03 xcp-ng-1 SM: [330]     self._remove_tag(vdi_uuid)
Aug 14 12:09:03 xcp-ng-1 SM: [330]   File "/opt/xensource/sm/blktap2.py", line 1452, in _remove_tag
Aug 14 12:09:03 xcp-ng-1 SM: [330]     assert sm_config.has_key(host_key)
Aug 14 12:09:03 xcp-ng-1 SM: [330]
Aug 14 12:09:03 xcp-ng-1 SM: [330] lock: closed /var/lock/sm/b7b8b6a2-6326-4402-9f95-96135bb1d2f7/vdi
Aug 14 12:09:03 xcp-ng-1 SM: [330] lock: closed /var/lock/sm/e6c74423-9152-b3b9-f503-efccde0e3edb/sr

XCP-ng update from XAPI

To avoid people doing a yum upgrade on each host manually, we could write a XAPI plugin that will be a simple interface to yum command.

Context

the plugin must be distributed as a rpm package first, and embed directly in future XCP-ng releases
XO should be able to detect if the plugin is here and run some scheduled checks. If the plugin is missing, XO should display a clear documentation on that. More to come in a dedicated XO issue.
XO should expose one button to update a whole pool at once (see future XO issue for this)

Design

We should do something simple at start (function calls could be renamed, it's just a draft):

check-update will use yum check-update command. Note than yum command returns exit value of 100 if there are packages available for an update. Also returns a list of the packages to be updated in list format. Returns 0 if no packages are available for update. Returns 1 if an error occurred. We should have something similar on the plugin return call, to be able to list packages to update and report errors etc.
update will call yum update -y to start the update process without confirmation (we should know what do update with check-update command previously called

We won't cover upgrade cases for now.

Cache

We could use XO as a cache to avoid downloading n times those packages (with n number of hosts in the pool).

Advanced usage

we should know when a reboot is needed on a host after updates. We need a way to detect that.

XCP-ng netinstall ISO

We could easily host a HTTP service with the XCP-ng ISO content and distribute then a small ISO doing a netinstall, pointing by default toward our HTTP

Add support for mdadm software raid.

User-Story:
I, as a non-profit or small business user would like to use software raid for my xcp-ng installation. This enables me to use a free xcp install on low end/budget hardware which does not offer a full hardware raid controller. Furthermore this enables me to order servers at cheaper providers such as Hetzner, Ovh, Online.net, etc. which do not offer hardware raid in their low end lines.

Note: XenServer never officially supported software raid. The usage of mdadm raid was only possible with manual tinkering.

Acceptance Criteria:

The installation iso supports the creation of mdadm based software raids.
Mdadm raid is supported for both, storage repositores as well as the base system.
Raid levels 0, 1, 10, 5, 6 are supported.
Optionally: The iso allows to upgrade existing XenServer installations that utilize mdadm.

XenServer package re-branding rfc

Purpose

Agree on a scheme for rebranding packages from xenserver/citrix to xcp-ng

Problem

As we fork XenServer, we will need to re-brand components in order to avoid being involved in a legal suit for infringing the original copyright.

Proposal

I would like to propose we approach the re-branding as follows:

For each package requiring re-brand (containing the words citrix or xenserver) we should:

create a corresponding github repo
import the source into this repo
tag each import in a way that it matches the version in the rpm source release (vanilla state)
Apply our re-branding changes

Thoughts from the core developers will be most appreciated, though we will gladly appreciate any feedback from the community as well.

place for XCP-ng Center to host update.xml

@olivierlambert can you please

create a place for XCP-ng Center to host it's update.xml and other release files?
or
let a subdomain like center.xcp-ng.org point to my server?
or
get in touch with me to find a good solution

Background: I dont want to implement the updatesystem for XCP-ng Center (permanently) based on github. For privacy and other reasons.

make command

I'm trying to install a drive from an USB NIC , but i can't do the 'make' command.
There is any official repo for installing the gcc from XCP-ng or there is any developer tools avaliable?

The NIC: D-Link dub-1312
Driver URL

Thank you!

New kernel security issue

remove trademarked logo from RPM package
check new RPM with rpmdiff
update to 7.5/updates(_testing) repository

Following the push of a new kernel to our repositories, some steps remain to be done:

Import source RPM to https://github.com/xcp-ng-rpms/kernel :

import_srpm.py -cp nameofsourcerpm.src.rpm . XS-7.5 XS-7.5

Pull changes to to branch 7.5. Solve conflicts if needed.
Rebuild kernel package
Push updated packages to the 7.5/builddeps repo (x86_64 + Source) so that future packages built while requiring the kernel headers or devel use the latest
Merge branch 7.5 to branch master

EMU manager

The package able to make vGPU migration is not Open Source. We should remove it from ISO.

XCP ISO upgrade on existing XS

That would be interesting to get to keep XAPI settings/VM/SR from a previous XS install, and install XCP "on top".

This would smooth transition from XS to XCP.

Dom0 memory demand is high alert even with 1GB+ of available memory

I'm receiving many alerts like "XenServer Alarm: Dom0 memory demand is high on "Control domain on host ETC". But if you log in and check the available memory, you can see there is more than 1GB of available memory for the Control Domain:

              total        used        free      shared  buff/cache   available
Mem:           3.8G        2.4G        156M        9.5M        1.2G        1.2G
Swap:          1.0G        975M         48M

Is this the desired behaviour? Or should I increase the memory available for the control domain?

Change Realtek RTL8139 to Intel E1000

Could you please make the Intel E1000 as default NIC when no PV Drivers are installed? The Intel E1000 NIC can 1GB/s and the Realtek can only do 100Mbit/s.
For example if you image an Virtual Machine, then this would be a lot faster with the E1000 NIC instead of the Realtek and the E1000 is also compatible with the most OS.

You have to tadd this Line "argv = [arg.replace('rtl8139','e1000') for arg in argv]" to def main(argv): in the File /usr/libexec/xenopsd/qemu-dm-wrapper.

The Section should looke like then:

def main(argv):

    argv = [arg.replace('rtl8139','e1000') for arg in argv]
    qemu_env = os.environ
    domid = int(argv[1])
    qemu_dm = qemu_dm_path(domid, argv)
    qemu_args = ['qemu-dm-%d'%domid] + argv[2:]

Please check if this can be implemented by default if wanted.

Feature: EXT4 Support for Thin Provisioning on Local SR

I would love to see better Thin Prov support in XCP-ng. Citrix XenServer uses outdated EXT3 for Thin Provisioned local SRs. I have a 14TB Local SR so the 2TB Max file-system limitation of EXT3 is frustrating, since I use hardware raid.

I see that there is plans to have ZFS support in the future. Would this be able to support Thin-Provisioning our is EXT4 the only hope for Local SRs larger than 2TB?

Thanks for all you've done so far! I am excited to try out the first XCP-ng ISO on some spare equipment!

FeatureReq - Support for USB NIC adapters with ASIX AX88179 chipset and similar

Support for USB NIC adapters would be really great, especially for those using Intel NUCs and other systems with only a single LAN Adapter.
Please note that in general this is not a driver issue, the adapter is recognized alright and the ethernet device is created. However it appears to be an interface naming issue in XenServer/xcp-ng: The name of the interface is not stable between reboots.
The issue is described and discussed here: https://discussions.citrix.com/topic/379716-usb-nic-with-xenserver-7/
People have devised manual workarounds, which most likely will not survive updates/upgrades. Still they can be useful as a starting point:
https://ericeikrem.com/index.php/en/how-tos/455-xenserver-lab-setup-usb-nic-gb

Want to upgrade XenServer 6.5 to XCP NG 7.4x remotely - possible ?

Hi devs,
I have a remote server running Xenserver 6.5, and want to upgrade it to latest XCP NG remotely. No, I do not have the access to reboot from DVD drive. Is it possible ?

XCP iso

Modifying the existing XS 7.4 ISO, we need to make it "XCP-ng" like.

It will require to:

Remaining user-visible XenServer branding

I think this is just cosmetic for now unless Citrix has a more serious problem with it.

There are a few places in the startup and shutdown sequence where the XenServer branding is still visible. If you press escape during the boot or disable Plymouth or use nosplash instead of splash as a kernel boot parameter, there are a few places in the text still showing XenServer instead of XCP or XCP-ng:

"welcome to" line which still shows as XenServer 7.4.0 It looks like this comes from the PRETTY_NAME field in /etc/os-release.

The others are places where XenServer still shows in the name of starting services in /usr/lib/systemd/system:

xs-sm.service
xsconsole.service
xapi-nbd.service

All still have XenServer in their descriptions which print out to the console whenever they are started or stopped.

I've manually edited them on my system and it doesn't seem to cause any problems. There are also instances of XenServer in:

the /etc/centos-release and other instances of it in the /etc/os-release files but I don't know if those are exposed to the user or not.

Feature: revive Xenconvert

Great effort so far, I am thrilled and looking forward to have community-driven Xenserver-like project.

For wider adoption of xcp-ng I see important to have Xenconvert revived and working both for Windows- and Linux-based OS-es. It was retired with the release of Xenserver 6.2 although in my experience it is quite important to have a tool for easy P2V migration. I am aware this could be with lower priority, but if it can be included in Phase 4, that would be really great!