Bug 1459831

Created attachment 1286097 [details]
remote host libvirtd

Created attachment 1286098 [details]
remote qemu log

Created attachment 1286100 [details]
local host qemu

Created attachment 1286101 [details]
guest xxml

This is a regression problem which does not exist in RHEL 7.3

Hi Dan,
  Can you tell me how much RAM your destination host has and whether it's running any other VMs?
  Does increasing the 'hard_limit' value in the XML help?

OK. I have to appologize this is a user error due to too small of hard_limit
With below section, the migration succeeds.

  <memory unit='KiB'>1048576</memory>
  <currentMemory unit='KiB'>1048576</currentMemory>
  <memtune>
    <hard_limit unit='KiB'>3145728</hard_limit>
    <swap_hard_limit unit='KiB'>4194304</swap_hard_limit>
  </memtune>

# virsh migrate --live --migrateuri rdma://192.168.100.2 setusertest --listen-address 0 qemu+ssh://192.168.100.2/system --verbose --rdma-pin-allroot.100.2's password: 
Migration: [100 %]

Hi Dan,
  Thanks for trying that;  can you tell me whether on 7.3 the original hard_limit value worked?

Hi David,
Currently I have no RDMA machines with RHEL7.3 for testing. I would like to try once I get them ready.

Hi, David,

After confirmation, the configuration in original XML like below can work in RHEL7.3. Thanks.

  <memory unit='KiB'>2097152</memory>
  <currentMemory unit='KiB'>2097152</currentMemory>
  <memtune>
    <hard_limit unit='KiB'>2097152</hard_limit>
    <swap_hard_limit unit='KiB'>2097152</swap_hard_limit>
  </memtune>

(In reply to Dan Zheng from comment #12)
> Hi, David,
> 
> After confirmation, the configuration in original XML like below can work in
> RHEL7.3. Thanks.
> 
>   <memory unit='KiB'>2097152</memory>
>   <currentMemory unit='KiB'>2097152</currentMemory>
>   <memtune>
>     <hard_limit unit='KiB'>2097152</hard_limit>
>     <swap_hard_limit unit='KiB'>2097152</swap_hard_limit>
>   </memtune>


Hi Dan,
  Can you try and figure out what component causes it to change;  for example for me with a 7.4 install and a 7.3 qemu it still fails.  So can you try with 7.3 kernel and 7.4 qemu etc and see which component it is that causes the change.

Thanks.

Hi David,

This is a known change that the hard_limit setting is different between rhel7.3 and rhel7.4. On rhel7.4 the memory hard_limit need be about 2G larger than the memory as our testing experience. There are bugs related to this issue such as Bz1373783. Btw, it's not easy for us to prepare the specific machines and set up env.

For more detail changes info, please confirm with QEMU QEs, that should be a more faster way. 


Thanks.

(In reply to yanqzhan from comment #14)
> Hi David,
> 
> This is a known change that the hard_limit setting is different between
> rhel7.3 and rhel7.4. On rhel7.4 the memory hard_limit need be about 2G
> larger than the memory as our testing experience. There are bugs related to
> this issue such as Bz1373783. Btw, it's not easy for us to prepare the
> specific machines and set up env.
> 
> For more detail changes info, please confirm with QEMU QEs, that should be a
> more faster way. 

I can't find any more details about it;  if it has doubled we need to understand why. bz 1373783 is just a documentation bug, it doesn't help - can you please provide some more information about what is known here.

> 
> 
> Thanks.

Sorry, it's misunderstanding between our group discussion. The larger hard limit requirement exists in previous product, refer to BZ1160997, BZ1046833. Maybe the xml configuration in comment12 (which mem equals to hard limit) needs further confirmation.

OK, that's fine - I'm only worried if it's a regression where the amount needed suddenly increases a lot.