Also check this article: we got a feature which should be very interesting in your case @DustinB3403 : https://xen-orchestra.com/blog/xenserver-emergency-shutdown/

@DustinB3403 said:

@olivier how well does XO work with APC Powerchute?

Because, that is my next goal. Get my VM's and Hosts to gracefully shutdown during a power-outage.

I strongly encourage people using it to contribute. You got 3 solutions:

• using xo-cli (from anywhere) to send basic orders to xo-server
• make a script using xo-lib if you want to make more advanced stuff
• write a xo-server plugin to manage that. But I don't know the APC product possibilities neither its API/callback capabilities.

Check our twitter (@xenorchestra) or blog, you won't miss it

edit: if you registered in our website for a XOA download, you'll receive an email

The lodash specific stuff won't be necessary after the 4.12

That's because the install process went bad, due to lodash issue (we reported it here)

So before the npm i, do a npm i [email protected].

If you want to stick on stable, a workaround would be npm i [email protected]

Build should be back on track on next-release branch.

It should also work on MacOS and Windows ^^

@scottalanmiller hahaha

@anonymous Experience ^^ (if the build fails).

In general, when there is a new big release of Node, dependencies can't catch the breaking changes for a time. That's why Node 5 broke the build for a time.

You can use the LTS version of Node to be safe: https://nodejs.org/en/blog/release/v4.2.0/

And now you discover why we release appliance with an updater and validated updates

Lodash team made a release 6 hours ago, and it broke everything. We are working on a way to avoid that, or reported this to them.

This stuff is sadly not very uncommon.

Don't mix node and npm version.

BTW, it should work with latest node version now.

@Dashrender Okay let's retake a clean example: one VM in a SR, with one 4GB VDI:

# lvscan 
  inactive          '/dev/VG_XenStorage-e27c48de-509f-3fec-d627-7f348062ab1a/MGT' [4.00 MiB] inherit
  inactive          '/dev/VG_XenStorage-e27c48de-509f-3fec-d627-7f348062ab1a/VHD-770ceeac-e97e-4e05-b9c5-892b97b9d16e' [4.02 GiB] inherit

After first snapshot:

# lvscan 
  inactive          '/dev/VG_XenStorage-e27c48de-509f-3fec-d627-7f348062ab1a/MGT' [4.00 MiB] inherit
  inactive          '/dev/VG_XenStorage-e27c48de-509f-3fec-d627-7f348062ab1a/VHD-38e2156f-da74-4edb-ac83-56fda54cfe55' [1.75 GiB] inherit
  inactive          '/dev/VG_XenStorage-e27c48de-509f-3fec-d627-7f348062ab1a/VHD-770ceeac-e97e-4e05-b9c5-892b97b9d16e' [4.02 GiB] inherit
  inactive          '/dev/VG_XenStorage-e27c48de-509f-3fec-d627-7f348062ab1a/VHD-f18856a5-039b-4d84-bf6c-a259d0f49a9e' [8.00 MiB] inherit

After second snapshot:

# lvscan 
  inactive          '/dev/VG_XenStorage-e27c48de-509f-3fec-d627-7f348062ab1a/MGT' [4.00 MiB] inherit
  inactive          '/dev/VG_XenStorage-e27c48de-509f-3fec-d627-7f348062ab1a/VHD-38e2156f-da74-4edb-ac83-56fda54cfe55' [1.75 GiB] inherit
  inactive          '/dev/VG_XenStorage-e27c48de-509f-3fec-d627-7f348062ab1a/VHD-f18856a5-039b-4d84-bf6c-a259d0f49a9e' [8.00 MiB] inherit
  inactive          '/dev/VG_XenStorage-e27c48de-509f-3fec-d627-7f348062ab1a/VHD-770ceeac-e97e-4e05-b9c5-892b97b9d16e' [4.02 GiB] inherit
  inactive          '/dev/VG_XenStorage-e27c48de-509f-3fec-d627-7f348062ab1a/VHD-68408f33-5a69-4b3b-afdd-a2cfabcad9ba' [8.00 MiB] inherit

As you can see, we got a second 8 MiB logical volume, nothing more (base parent and active VDI doesn't change).

Let's remove the latest snapshot:

# lvscan 
  inactive          '/dev/VG_XenStorage-e27c48de-509f-3fec-d627-7f348062ab1a/MGT' [4.00 MiB] inherit
  inactive          '/dev/VG_XenStorage-e27c48de-509f-3fec-d627-7f348062ab1a/VHD-38e2156f-da74-4edb-ac83-56fda54cfe55' [1.75 GiB] inherit
  inactive          '/dev/VG_XenStorage-e27c48de-509f-3fec-d627-7f348062ab1a/VHD-f18856a5-039b-4d84-bf6c-a259d0f49a9e' [8.00 MiB] inherit
  inactive          '/dev/VG_XenStorage-e27c48de-509f-3fec-d627-7f348062ab1a/VHD-770ceeac-e97e-4e05-b9c5-892b97b9d16e' [4.02 GiB] inherit

It removes the previously created volume, as expected. Now, let's remove the initial snapshot. Durin few seconds, we'll have this:

lvscan 
  inactive          '/dev/VG_XenStorage-e27c48de-509f-3fec-d627-7f348062ab1a/MGT' [4.00 MiB] inherit
  inactive          '/dev/VG_XenStorage-e27c48de-509f-3fec-d627-7f348062ab1a/VHD-38e2156f-da74-4edb-ac83-56fda54cfe55' [1.75 GiB] inherit
  inactive          '/dev/VG_XenStorage-e27c48de-509f-3fec-d627-7f348062ab1a/VHD-770ceeac-e97e-4e05-b9c5-892b97b9d16e' [8.00 MiB] inherit
  inactive          '/dev/VG_XenStorage-e27c48de-509f-3fec-d627-7f348062ab1a/leaf_770ceeac-e97e-4e05-b9c5-892b97b9d16e_38e2156f-da74-4edb-ac83-56fda54cfe55' [4.00 MiB] inherit

But it will be automatically "garbage collected" when the system will see than the chain doesn't have any snapshot in it (after few seconds in this case):

# lvscan 
  inactive          '/dev/VG_XenStorage-e27c48de-509f-3fec-d627-7f348062ab1a/MGT' [4.00 MiB] inherit
  inactive          '/dev/VG_XenStorage-e27c48de-509f-3fec-d627-7f348062ab1a/VHD-770ceeac-e97e-4e05-b9c5-892b97b9d16e' [4.02 GiB] inherit

We are back to the initial situation.

By the way, you can spot the difference with a thin provisioned SR, like NFS in this case:

Far better...

@Dashrender It's not exactly like that on a thick storage. It's a little bit more complicated in fact.

It depends of the current disk content. XenServer will try to deflate as possible. Let's take for example, only one VDI with the total size of the disk space provisioned (let's say on a LVMoiSCSI):

Then, if you do a snapshot, you'll have 3 disks:

• the original one will become the parent
• the new created active VDI will be remapped to be current VM disk
• the snapshot

Doubling size is the worst case, when deflate won't free some space (or very little). In this case, the initial snapshot mechanism will double the space used.

But any extra snapshot (after the initial one) won't consume a lot of space.

@johnhooks If you are on a XenServer pre-Dundee, that's normal: LVM is not thin provisioned in this case.

About thin provisioning in next XenServer version (Dundee):

THIN PROVISIONED BLOCK STORAGE

iSCSI and HBA block storage can now be configured to be thinly provisioned. This is of particular value to those users who provision guest storage with a high water mark expecting that some allocated storage won't be used. With XenServer 6.5 and prior, the storage provider would allocate the entire disk space which could result in a significant reduction in storage utilization which in turn would increase the cost of virtualization. Now block storage repositories can be configured with an initial size and an increment value. Since storage is critical in any virtualization solution, we are very interested in feedback on this functional change.

Source: http://xenserver.org/discuss-virtualization/virtualization-blog/entry/xenserver-dundee-beta-1-available.html

I have to make some tests on my side.

And sadly that's nothing we can do about it ^^

@DustinB3403 Even classical backup: for a running VM we need to export the snapshot. So if all your VMs are running and you are backuping everything at once, you'll need to double your space usage (at least during the VM export process).

That's why it's important to use thin provisioned storage as possible.

@johnhooks To avoid the "re-importing" step that you need with classical backup

Backup:

• exporting somewhere (any filesystem)
• re importing when need (import time)

DR:

• streaming somewhere (another XenServer host)
• ready to start on the target if needed

edit: so it seems similar but it's not for the same use case.