[Users] strange permission issue on migration

[Dmitry Konstantinov]

Whatever those containers have inside doesn't explain the fact
that they have no problem migrating to another server. I assume
if there was something wrong with the container itself it would
refuse to move regardless of the destination.

and yes, no problem moving 'manually' with rsync / transferring a 
tarball. Though I'd recommend to pass '--numeric-ids --sparse' to tar.

And I still don't understand why does offline migration make a snapshot
on source.

On Sun, 16 Feb 2020 14:08:06 -0300
Paulo Coghi - Coghi IT <paulocoghi at gmail.com> wrote:

> It could be that those containers contains specific file types that
> are presenting problems when vzmigrate is operating the rsync command.
> 
> I see two possible workarounds/solutions.
> 
> *First:*
> Execute the rsync yourself manually (without vzmigrate), and register
> the container on the new host after migration, with "prlctl register
> /vz/private/<container_id>". Use the following flags:
> 
> rsync -az -H -X --one-file-system --numeric-ids /vz/private/123456/
> -e ssh root@<server_hostname_or_ip>:/vz/private/123456/
> 
> The "-H" flag preserves hard-links and "-X" preserves extended
> attributes. The "z" on "-az" is optional, to compress the data during
> transfer.
> 
> 
> *Second:*
> Compress the container's private directory to generate a .tar(.gz)
> file, and transfer it. Use the -p flag to preserve owners when
> creating the .tar(.gz) and --same-owner when extracting it on the new
> host:
> 
> tar -zcpf 12345.tar.gz /vz/private/12345
> 
> The "z" is to generate a /tar.gz instead of a .tar. Generating a .tar
> is much faster, but occupying more space. Generating a .tar.gz is
> slower, but it occupies less space and is faster to transfer.
> 
> 
> Please do a test and provide a feedback!
> 
> 
> Paulo Coghi
> 
> On Fri, Feb 14, 2020 at 5:59 PM Dmitry Konstantinov
> <barmaley at barmaley.net> wrote:
> 
> > yes I do.
> >
> > It happens often when we do mass migrations to free
> > a server for maintenance. One or maybe two containers
> > refuse to migrate no matter what.
> >
> > On Fri, 14 Feb 2020 16:49:22 -0300
> > Paulo Coghi - Coghi IT <paulocoghi at gmail.com> wrote:
> >  
> > > Hi, Dmitry!
> > >
> > > I usually temporarily enable access to the root user on SSH to
> > > proceed with the migrations.
> > >
> > > Are you using root?
> > >
> > > On Thu, Feb 13, 2020 at 12:37 PM Dmitry Konstantinov
> > > <barmaley at barmaley.net> wrote:
> > >  
> > > >
> > > > I am pretty sure it's not permissions however that's what
> > > > reported by vzmigrate.
> > > >
> > > > offline migration fails with the messages:
> > > >
> > > > copy CT private /vz/private/24060
> > > > rsync : rsync: rename
> > > > "/vz/private/24060/root.hdd/.root.hds.dkD99G" ->
> > > > "root.hdd/root.hds": Operation not permitted (1) rsync : rsync:
> > > > rename 
> > "/vz/private/24060/root.hdd/.root.hds.{ed04b7fe-4084-42ec-864d-edc1ae4b03d5}.eVcsbD"
> >  
> > > > -> "root.hdd/root.hds.{ed04b7fe-4084-42ec-864d-edc1ae4b03d5}":  
> > > > Operation not permitted (1)
> > > > rsync : rsync error: some files/attrs were not transferred (see
> > > > previous errors) (code 23) at main.c(1055)
> > > > [sender=3.0.9]
> > > >
> > > > Subsequent runs show similar errors, removing private area on
> > > > destination (we use --keep-dst) doesn't help, renaming it so the
> > > > next attempt to migrate would use different location on the
> > > > device doesn't help. However the migration to another server
> > > > usually works.
> > > >
> > > > Any ideas what might be the problem?
> > > >
> > > > BTW is there any reason for vzmigrate to create a snapshot when
> > > > migrating offline?
> > > >
> > > > Thanks,
> > > > Dmitry.
> > > >
> > > >
> > > > _______________________________________________
> > > > Users mailing list
> > > > Users at openvz.org
> > > > https://lists.openvz.org/mailman/listinfo/users
> > > >  
> >
> > _______________________________________________
> > Users mailing list
> > Users at openvz.org
> > https://lists.openvz.org/mailman/listinfo/users
> >