In the Virtualization guide for openSUSE Leap 15.2 page 47 section 9.7.1 Migration Requirements there is this requirement for migration
All VM Host Servers participating in migration must have the same UID for the qemu user
and the same GIDs for the kvm, qemu, and libvirt groups.
But everytime I install openSUSE Leap 15.2 in a host a different UID in assigned for that user and a different GID for those groups, How do you manage to make this UID and these GIDs to be the same in all host?
Is there a script or a procedure to achive this safely?
moreover, the document 7008168 in SUSE states that to manage VM using HAE interface you should be able to do one live migration using virsh command line or virtual manager, so you must first setup KVM live migration before leveraging HA in linux.
I haven’t done this (KVM migration) but I think I see the reasoning behind the requirement… The permissions for the running virtualization tools on each HostOS has to be the same to have same access to shared resources the migrating Guest is using. That’s interesting if you say that the UID and GID are different in each machine, I wouldn’t have expected that… Maybe it’d actually be a security hole if those IDs were standardized? I’d have to think about that…
There are likely a couple ways you can modify the QEMU UID and the GIDs for the KVM, QEMU and LIBVIRT groups…
Use the command line utilities setuid and setgid
Use YaST on the HostOS. You should see the UID in the “Details” tab and the GID in the “Group” tab. In both cases, you can change the number and I expect that would save those changed values.
I haven’t actually done this, so you might want to do a little testing in a thowaway Guest to verify the behavior is as expected.
Hi
The switch to systemd user groups will fix this issue, already in Tumbleweed. But as indicated since they are likely created as ‘system’ users in Leap it just picks the next available uid/gid, need to configure manually
You create these users and groups in advance, before installing packages that need them. This is nothing new, any cluster configuration with shared storage/filesystem depends on having identical credentials for the same users on each system. In case of Unix/Linux “credentials” means UID and GID. When you deploy such configuration you are responsible for maintaining consistent user view on all involved systems.
Or you are using centralized user management via LDAP or similar. But then you still need to enter proper users and groups into this central management system.
Or you use Salt/Chef/Puppet/Ansible/… to automate setup of your hosts and apply consistent settings. Which you still need to configure and setup
Is there a script or a procedure to achive this safely?
Not sure what “safely” means here. You use useradd and groupadd before installing your packages.
Of course, it makes sense to chose UID and GID matching current Tumbleweed defaults, to make sure updated system and newly installed systems will have the same settings in the future.
to manage VM using HAE interface you should be able to do one live migration using virsh command line or virtual manager, so you must first setup KVM live migration before leveraging HA in linux.
You got it backwards. Linux HA does not need live migration to manage VM. Linux HA supports live migration and can utilize it if it is properly set up (or better - pacemaker understands that resource is moved from one host to another and provides commands to initiate migration), but it does not require it. In the worst case you stop VM on one host and start on another. Just like any other resource.
But even without live migration Linux HA cluster is perfect example of configuration with shared storage so you must ensure identical credentials on each host anyway. And not only for users needed by libvirt, but for any user that owns resources that may fail over to another host.
In an ideal world, the UID and GID would be re-configured before any packages (actually files I’m pretty sure since the security filesystem bits are set on files) are installed.
But, would what is suggested in the openSUSE virtualization documentation work, to alter the ID numbers later?
Am guessing but from what I’ve seen that the ID number stands on its own and doesn’t set specific permissions on each file, so changing the ID numbers shouldn’t cause problems.
And, the UID and GID numbering scheme is strictly flat and not hierarchical (like there is in MSWindows) so you don’t have a dependency or Parent/Child inheritance problem.
After a bit of reading,
Apparently KVM supports both what is called a “live migration” when both source and target machines are active, and so would need to have identical or at least perfectly equal access to shared resources… ie memory blocks and addresses, and storage. There is also an “offline migration” we normally think of where after transfer the source shuts down and the target simultaneously starts up. Of course, the “live migration” offers practically zero downtime where the “offline migration” might be expected to be offline for seconds to minutes even in a HA setup.
Not having personally done a KVM migration before (have in other situations), the openSUSE documentation curiously has signs of being an offline type migration yet prerequisites are what is required in a “live migration.” So, I’d have to actually set up and observe to really know what’s going on.
I also think there is some misunderstanding of HA vs Live migration…
HA ensures a high level QoS/availability even in the event of unexpected failure.
Live migration is not a HA solution that activates or solves availability objectives, Live migration is a planned event that happens when invoked intentionally.
As such, although there may be some similarities, they solve different objectives.
I found this information, they solved the issue assignig the same uid and gid instead of the random behavior
While a virtual machine (VM) is running its image files are owned by user libvirt-qemu and grouplibvirt-qemu to prevent other processes from accessing those files concurrently. Until UCS-4.2 the
numeric user ID (UID) and group ID (GID) were allocated dynamically during Debian package
installation. This leads to the named user having different numerical IDs, which breaks Live
migration over Network File System: NFS works only with the numeric IDs. So while a VM is
running on one host, a second host cannot access the same file as it has a different numeric
mapping.
To solve this Debian switched to a static mapping after allocating UID 64055 and GID 64055
permanently to that user / group. This was fixed in Debian Jessie 8, which was imported into UCS4.2.
Since then the static IDs are used.
Looks like both your resources should work, none of the commands and procedures in each look like they are specific to Debian and won’t work in an RPM system like openSUSE.
Congrats on your research.
Only slight correction is that I doubt that you need to stop the services completely before modification, AFAIK the usermod and groupmod commands can be executed on a running system but services will need to be restarted before they take effect. For systems that absolutely need to minimize downtime, these seconds or minutes difference in downtime might be important.
Rounding back to why my recommendation to use setid and setgic aren’t the right tools, those are what would be used to apply settings to a specific file whereas the proper approach is to modify the uid and gid. Someone with time on their hands might experiment with using YaST to modify those as well.
