[pbs-devel] Templates starting on backup

[pbs-devel] Templates starting on backup

[Graeme Seaton]

Hi,

I store my templates on a common host and move to deployment host as 
necessary.  Unfortunately, when backup up the process tries to start the 
template and then fails if there is a difference in the hardware 
configuration between the current host and it's definition.

Given that templates (if I understand correctly) are not run directly 
shouldn't the backup just work with the images since there won't be any 
dirty blocks to be detected?

Regards,

Graeme

Re: [pbs-devel] Templates starting on backup

[Thomas Lamprecht]

Hi,

On 05.10.20 14:15, Graeme Seaton wrote:
> I store my templates on a common host and move to deployment host as necessary.  Unfortunately, when backup up the process tries to start the template and then fails if there is a difference in the hardware configuration between the current host and it's definition.
> 
> Given that templates (if I understand correctly) are not run directly shouldn't the backup just work with the images since there won't be any dirty blocks to be detected?
> 

Yes, they have no dirty bitmap by definition, but we start them up so that
we can re-use our QEMU backup integration for PBS. The VM is not started for
real, just a QEMU process is running - this shows up in the webinterface
(because it's a cheap check) - but the backup lock symbol should avoid
confusions.

Re-using the QEMU built in block drivers to access the templates disks allows
to avoid duplicating quite some logic and functionality, and solves a few
edge cases "for free". That's the main reason we use it here.


What HW differences are talking here?

cheers,
Thomas

Re: [pbs-devel] Templates starting on backup

[Graeme Seaton]

Hi,

In one case CPU type/Numa/hugepages.  In others vmbr's.

Regards,

Graeme

On 05/10/2020 14:42, Thomas Lamprecht wrote:
> Hi,
>
> On 05.10.20 14:15, Graeme Seaton wrote:
>> I store my templates on a common host and move to deployment host as necessary.  Unfortunately, when backup up the process tries to start the template and then fails if there is a difference in the hardware configuration between the current host and it's definition.
>>
>> Given that templates (if I understand correctly) are not run directly shouldn't the backup just work with the images since there won't be any dirty blocks to be detected?
>>
> Yes, they have no dirty bitmap by definition, but we start them up so that
> we can re-use our QEMU backup integration for PBS. The VM is not started for
> real, just a QEMU process is running - this shows up in the webinterface
> (because it's a cheap check) - but the backup lock symbol should avoid
> confusions.
>
> Re-using the QEMU built in block drivers to access the templates disks allows
> to avoid duplicating quite some logic and functionality, and solves a few
> edge cases "for free". That's the main reason we use it here.
>
>
> What HW differences are talking here?
>
> cheers,
> Thomas
>
>

Re: [pbs-devel] Templates starting on backup

[Thomas Lamprecht]

On 05.10.20 16:21, Graeme Seaton wrote:
> On 05/10/2020 14:42, Thomas Lamprecht wrote:
>> What HW differences are talking here?
>
> In one case CPU type/Numa/hugepages.  In others vmbr's. 

Why not just leave it at the "OK" hosts, if you're using HA you could
add it to a group restricted to those hosts it is compatible with.

We may reduce the configuration of a template started fort backup a bit,
though.

cheers,
Thomas

Re: [pbs-devel] Templates starting on backup

[Graeme Seaton]

The reason I moved them was that my sense of taste didn't like having 
the templates intermingled with the running hosts in the server view ;-)

Having all of the templates stored on a single host also provides a very 
simplistic way of making sure the running VM's are backed up as quickly 
as possible without being delayed by templates on the same server.  
Being on a single host means that the templates are backed up on a 
single separate 'thread'.  I could probably achieve something similar by 
placing all of the templates in a very high id range.

No biggie - just thought I'd feed back about the failures.

Regards,

Graeme

On 05/10/2020 15:40, Thomas Lamprecht wrote:
> On 05.10.20 16:21, Graeme Seaton wrote:
>> On 05/10/2020 14:42, Thomas Lamprecht wrote:
>>> What HW differences are talking here?
>> In one case CPU type/Numa/hugepages.  In others vmbr's.
> Why not just leave it at the "OK" hosts, if you're using HA you could
> add it to a group restricted to those hosts it is compatible with.
>
> We may reduce the configuration of a template started fort backup a bit,
> though.
>
> cheers,
> Thomas
>
>