libvirt users - Aug 2014 - Re: username and passwd after create VM from XML dump

On Wed, Aug 6, 2014 at 1:29 PM, Eric Blake <eblake@redhat.com> wrote:
> On 08/06/2014 11:11 AM, Yuanzhen Gu wrote:
>
> >> Libvirt is only concerned with what virtual hardware you present
to the
> >>
> >> guest, not with the OS running in that guest or what
username/password
> >>
> >> combinations will let you log into that guest OS.  libguestfs may
be
> >>
> >> able to do some introspection for learning usernames, and also has
the
> >>
> >> ability to create guest clones where you control the usernames and
> >>
> >> passwords to be used in the new guest.
> >>
> >>
> >        Thanks!  so do you mean that I can use libvirt clone a new
guest
> > with which I can give username and password?
>
> Libvirt can just copy guest storage and hardware configuration.  If you
> use only libvirt to do a guest clone, then the clone will have the same
> OS credentials as the original.  That's probably not what you want.
>
> You seem to be asking about libguestfs - but that's a higher-level
> application than libvirt, so you may want to migrate your questions to
> the libguestfs list.  http://libguestfs.org/virt-sysprep.1.html gives an
> overview of the sort of things you can do when prepping a cloned system
> via libguestfs, such as setting up a known account with a known password.
>
>
> >       but I've no idea where the username and passwd be stored,
create it
> > with dumpXML of a VM, I've tried that original VM's username
and passwd
> via
> > ssh, but it didn't work.
>
> Again, libvirt could care less what passwords your guest OS uses, as
> passwords are not hardware, so dumpxml is unable to show you that
> information(well, you COULD use libvirt's virDomainSetMetadata to store
> custom XML that records that information, and then dumpxml would repeat
> back the custom XML you associated with the guest - but again, that's
> something you do as management, and not something libvirt tracks
> natively).  Libguestfs knows how to introspect guest file systems, and
> may help you create a new password, but if you were careless enough to
> lose track of what password an existing guest was using, I seriously
> doubt there is anything that we can do to help you recover that
> password, at least if it was stored securely by the guest OS.
>
    I see, thank you so much Eric!
    Just one more question to make me clear in this point, so if I install
an application in the guest, and make a dmup XML, then     create a new
guest using that configured dump XML file, the new guest should also have
that application installed?  and the username and password of the new guest
should be the same as the previous guest?   thanks a lot!
>
>
 --
> Eric Blake   eblake redhat com    +1-919-301-3266
> Libvirt virtualization library http://libvirt.org
>
>

On 08/06/2014 12:10 PM, Yuanzhen Gu wrote:
>     Just one more question to make me clear in this point, so if I install
> an application in the guest, and make a dmup XML, then     create a new
> guest using that configured dump XML file, the new guest should also have
> that application installed?  and the username and password of the new guest
> should be the same as the previous guest?   thanks a lot!
dumpxml is only half a guest.  A guest consists of the hardware it is
running on (dumpxml) and the contents of the disks (storage volumes).
To create a clone, you need to copy and modify both the dumpxml domain
description, AND do a clone (or share a common base file, using qcow2
overlays) of the disk elements (where part of your xml edits is pointing
to the just-cloned storage).  Furthermore, if you expect both the
original and the new guest to ever run in parallel, it is a very wise
idea to do other changes to the disk contents (which is why I pointed
you to libguestfs' virt-sysprep).  For example, if you forget to nuke
the guest's random number seed, then both the original and the guest
will be using the same random number stream when they first boot, which
is a security hole waiting to happen because random streams are not
supposed to be predictable.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

On Wed, Aug 6, 2014 at 3:07 PM, Eric Blake <eblake@redhat.com> wrote:
> On 08/06/2014 12:10 PM, Yuanzhen Gu wrote:
> >     Just one more question to make me clear in this point, so if I
> install
> > an application in the guest, and make a dmup XML, then     create a
new
> > guest using that configured dump XML file, the new guest should also
have
> > that application installed?  and the username and password of the new
> guest
> > should be the same as the previous guest?   thanks a lot!
>
> dumpxml is only half a guest.  A guest consists of the hardware it is
> running on (dumpxml) and the contents of the disks (storage volumes).
> To create a clone, you need to copy and modify both the dumpxml domain
> description, AND do a clone (or share a common base file, using qcow2
> overlays) of the disk elements (where part of your xml edits is pointing
> to the just-cloned storage).  Furthermore, if you expect both the
> original and the new guest to ever run in parallel, it is a very wise
> idea to do other changes to the disk contents (which is why I pointed
> you to libguestfs' virt-sysprep).  For example, if you forget to nuke
> the guest's random number seed, then both the original and the guest
> will be using the same random number stream when they first boot, which
> is a security hole waiting to happen because random streams are not
> supposed to be predictable.
>
    Thank you very much Eric !
>
> --
> Eric Blake   eblake redhat com    +1-919-301-3266
> Libvirt virtualization library http://libvirt.org
>
>