[Users] Migration issues with ovirt 3.3

[Gianluca Cecchi]

Il 09/ott/2013 15:39 "Gianluca Cecchi" <gianluca.cecchi at gmail.com> ha
scritto:
>
>
> Il 09/ott/2013 15:35 "Dan Kenigsberg" <danken at redhat.com> ha scritto:
>
> >
> > On Wed, Oct 09, 2013 at 02:27:16PM +0200, Gianluca Cecchi wrote:
> > > On Tue, Oct 8, 2013 at 12:27 PM, Omer Frenkel wrote:
> > >
> > > >> >
> > > >> > so now I'm able to start VM without having to select run once and
> > > >> > attaching a cd iso
> > > >> > (note that is only valid for newly created VMs though)
> > > >>
> > > >> Yes. Old VMs are trashed with the bogus address reproted by the
buggy
> > > >> Vdsm. Can someone from engine supply a script to clear all device
> > > >> addresses from the VM database table?
> > > >>
> > > >
> > > >
> > > > you can use this line (assuming engine as db and user), make sure
only 'bad' vms return:
> > > > psql -U engine -d engine -c "select distinct vm_name from
vm_static, vm_device where vm_guid=vm_id and device='cdrom' and address
ilike '%pci%';"
> > > >
> > > > if so, you can run this to clear the address field for them, so
they could run again:
> > > > psql -U engine -d engine -c "update vm_device set address='' where
device='cdrom' and address ilike '%pci%';"
> > > >
> > >
> > > I wanted to test this but for some reason it seems actually it solved
itself.
> > > I first ran the query and already had no value:
> > > engine=# select distinct vm_name from vm_static, vm_device where
> > > vm_guid=vm_id and device='cdrom' and address ilike '%pci%';
> > >  vm_name
> > > ---------
> > > (0 rows)
> > >
> > > (overall my VMs are
> > > engine=# select distinct vm_name from vm_static;
> > >   vm_name
> > > -----------
> > >  Blank
> > >  c6s
> > >  c8again32
> > > (3 rows)
> >
> > Which of these 3 is the one that was started up with an empty cdrom on a
> > vanilla ovirt-3.3.0 vdsm? The script is expect to show only those.
>
> It is c6s

Note that the query suggested by Omer had 0 rows.
My further query with 3 results was to show you all rows from vm_static at
the moment
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/users/attachments/20131009/c8f30583/attachment.html>