[libvirt] [PATCH v2 1/4] conf: s/virDomainObjGetShortName/virDomainDefGetShortName/

[Michal Privoznik]

On 11/02/2017 12:11 AM, John Ferlan wrote:
> 
> 
> On 10/24/2017 07:41 AM, Michal Privoznik wrote:
>> This function works over domain definition and not domain object.
>> Its name is thus misleading.
>>
>> Signed-off-by: Michal Privoznik <mprivozn at redhat.com>
>> ---
>>  src/conf/domain_conf.c   | 4 ++--
>>  src/conf/domain_conf.h   | 2 +-
>>  src/libvirt_private.syms | 2 +-
>>  src/qemu/qemu_conf.c     | 2 +-
>>  src/qemu/qemu_domain.c   | 4 ++--
>>  src/qemu/qemu_driver.c   | 2 +-
>>  6 files changed, 8 insertions(+), 8 deletions(-)
>>
> 
> Reviewed-by: John Ferlan <jferlan at redhat.com>
> 
> John
> 
> BTW: I wonder if this function is somewhat broken - it's using def->id
> in order to generate the output, right?  Which means for paths generated
> before the guest starts, they'll start with "-1"...  IOW: Directory and
> file names that start with "-".
> 
> This wasn't a problem originally (commit id a042275a) since the
> resulting path had "domain-" prepended to it - resulting in
> "domain--1-QEMUGuest1, for example).
> 
> Personally, this looks REALLY odd when (re)using for example with a
> hugepage test where the path is "-mem-path
> /dev/hugepages2M/libvirt/qemu/-1-QEMUGuest1".

This is because we don't set an ID for domains when testing. However, in
real scenarios this function is called over running domains. Therefore,
the path will always start with a natural number. I don't think there's
anything to fix really. We could go with "domain-" prefix but that'd be
no better in fact. Yes, it would help with 'rm' case but other than that
it has no added value.

Michal